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GLOSSARY OF TERMS 


Many terms contained in this document have meanings specific to flight deck design or arc 
defined differently by different organizations. They are defined here to help reduce confusion and 
ambiguity. 

Anthropometries: Measures of human physical dimensions, including not only static measures of 
body dimensions (e.g., height or arm length) but also functional measures such as reach and grip span 
and performance characteristics such as strength and viewing distance. Descriptions of the variability 
associated with these measures are also included to cover the different potential user populations. 

Assumption: An assumption is something taken for granted; a supposition. It is typically a statement 
whose truth or falsehood is untestable, but is believed to be true. In the case of the HSCT, this occurs 
because many of the assumptions pertain to future conditions or events. 

Automation: Systems or machines which perform a function or task. For example, automation can 
replace humans (perform an entire task), augment them (perform a part of some control activity), or aid 
them (provide computation to assist human information processing, decision making, recall, etc.). 

Cognitive Engineering: An applied cognitive science that draws on the knowledge and techniques of 
cognitive psychology and related disciplines to provide the foundation for principle-driven design of 
person-machine systems. 

Control Display Unit (CDU): One of the flight crew interface devices used to communicate with the 
Flight Management System (FMS). The CDU consists of numeric and alphabetic keypads, function 
and page select keys, a small display screen, and line select keys arranged on the sides of the display 
screen to correspond to specific lines on the display pages. 

Crew Resource Management (CRM): Sometimes referred to as cockpit resource management or 
command leadership resource management, this is a technique by which each crew member, especially 
the Captain, effectively uses all available sources of information and assistance to handle abnormal or 
emergency situations. 

Critical Flight Functions: Those functions which are essential for the safe and successful completion 
of the flight. This term is used instead of “flight critical,” which can have a very specific legal meaning 
in some contexts. 

Design and Integration Element: One of the three main elements within the High Speed Research 
(HSR) program’s Flight Deck effort. The other two Elements are External Visibility and Guidance & 
Control. 

Design Philosophy: The design philosophy, as embodied in the top-level philosophy statements, 
guiding principles, and design guidelines, provides a core set of beliefs used to guide decisions 
concerning the interaction of the flight crew with the aircraft systems. It typically deals with issues 
such as function allocation, levels of automation, authority, responsibility, information access and 
formatting, and feedback, in the context of human use of complex, automated systems. 

Dynamic Function Allocation: A methodology for allocating functions among various team members 
(humans and automated systems) adaptively, as a situation develops, to make the best possible use of 
the resources that each team member can contribute to the effort taking into consideration the other 
tasks that may be underway. 


Engineering Psychology : A specialized area within the field of human factors research which focuses 
on basic investigations into fundamental human capabilities and limitations. 


Error Correction : A capability, human or automated, to "undo” 
was erroneous and then perform the correct action or response. 


or reverse an action or response that 


Error Detection : A capability, human or automated, to determine that an error has occurred. 

Error Prevention : A capability, human or automated, to prevent errors from occurring. For example 
an input device may only allow entry of numbers that are valid for the operational context. 

Error Tolerance: A capability, human or automated, to compensate or adjust for the occurrence of an 
error so that it has no significant consequences in terms of flight safety. 

Final Integrated Design: At this stage in the design process the various flight deck systems are 
integrated into a total flight deck. The flight crew interface with each of the aircraft subsystems is also 


Flight Deck Features: Aspects of the flight deck which are used by designers to differentiate and 
organize their design experiences. These features have been categorized here as displays controls 
automation, and alerting. 

Flight Management System (FMS): The total computer-based system for planning the flight of the 
aircratt and providing guidance and autoflight control capabilities. It includes multiple Flight 
Management Computers (FMC's), the Mode Control Panel (MCP), and multiple Control Display 
Units (CDU s), and is linked to many other aircraft subsystems and controls. 

Function Allocation. The process of determining which team members (flight crew or automated 
systems) will nominally be performing specific functions and tasks. Specific function allocations may 
occur during the design process, and others may be left to the discretion of the flight crew (see 
Dynamic Function Allocation). 

Guideline: This is an indication or outline of policy or conduct A guideline provides design guidance 
more specific than a principle, such as at the system level, interface level, or specific factor level (e g 
fighting). Guidelines arc concerned with function and form of flight deck design. Quantification of 
and adnerence to guidelines is relative; in contrast, quantification of and adherence to requirements is 


High Speed Civil Transport (HSCT): A proposed supersonic commercial airliner capable of long 
range flights at speeds of up to Mach 2 . 4 . 6 


High speed Research (HSR) Program: A joint research program by NASA and the U S. commercial 
aviation industry, initiated with the goal of establishing the technological base needed to reduce the risk 
associated with the design and development of the HSCT. 


Human-Centered Automation : A concept of aircraft automation in which the flight crew members 
perceive themselves to be at the locus of control of the aircraft and all of its systems, regardless of the 
current control mode or level of automation in use (Bil'ings, 1991 ). 

Human Engineering: The practice of applying knowledge of the disciplines of anthropometry, 

psychology, biology, sociology, and industrial design to the development of products or processes 
that involve human interaction. F 


Inductive Reasoning: Inference of a generalized conclusion from particular instances. 
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Initial Design Concepts : This stage of the design process represents both the process and the product 
of allocating specific functions to either the human pilots or the automated systems, and then 
developing alternative design concepts to support that allocation of functions and selecting from among 
those concepts. For example, initial design concepts related to the function of maintaining runway 
centerline during landing rollout may include multiple types of control inceptors (rudder pedals or a 
hand crank) and control laws (different rates, gains, etc.) for the pilot, and various control laws for the 
autoflight system. 

Levels of Automation: The degree to which a function or task is performed by the human and 
automated systems. The highest level of automation is characterized by automated systems performing 
the function autonomously without any pilot input. The lowest level of automation is characterized by 
pilot performance of a task or function with no assistance from automation. 

Mental Model : An understanding on the part of the flight crew member of how a particular device or 
automated system works in terms of its internal structure or processes. This understanding may be at a 
high level, dealing only with general notions of how something works, or may be very specific, 
dealing with intricate details and system knowledge. 

Mode Control Panel (MCP): The collection of controls and displays used by the flight crew for 
entering speed, lateral, and vertical control instiuc lions to the autoflight system. This panel is usually 
mounted on the flight deck glareshield, and, depending on the aircraft manufacturer, may be referred to 
as a Guidance and Control Panel (GCP) or Flight Control Panel (FCP). 

Multiple Resource Theory: The theory that humans have multiple input and output channels, such as 
vision, hearing, smell, and speech, that can be time-shared most effectively when the different 
resources being used are the most unrelated. 

Next Generation Flight Deck: The next-generation flight deck is defined by a design process less 
constrained by past design practices and more conducive to gathering and applying recent research 
Findings and state-of-the-art knowledge about the design and operation of complex man-machine 
systems. The next generation flight deck also includes a greater focus on human-centered issues in the 
design process. This new approach may or may not result in a flight deck that is radically different 
from current flight decks. 

Objective: This is something that one's efforts are intended to attain or accomplish; a purpose; a goal; a 
target. Multiple objectives usually must be met, and the flight deck designer should understand the 
relationships among these objectives, and their relative importance. 

Operability : Operability is sometimes used synonymously with usability, that is, can a system be 
operated safely and efficiently by a user such as a pilot. It is used more broadly here to include not 
only usability but also functionality, that is, when the system is operated, does it meet the functional 
requirements? 

Philosophy In general, a philosophy is a system of beliefs or a doctrine that includes the critical study 
of the basic principles for guidance in practical affairs. For the purposes of this document, the 
guidance in this case is specific to flight crew issues relevant to commercial flight deck design. 

Philosophy statements . High-level statements summarizing a general position or perspective, in this 
case, a philosophy of flight deck design. 

Principle: This is a fundamental, primary, or general law or axiom from which others are derived; a 
fundamental doctrine or tenet; a distinctive ruling opinion. In this document, a principle provides 
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design guidance at the flight deck function level, and refers to general concepts such as authority, 
function allocation, levels of automation, human information processing capabilities, etc. 

Requirement: This is something that is necessary or essential. A requirement describes a specific 
condition that the design must meet, and can be traced back to limitations imposed by various "outside" 
requirements or constraints (e.g., what the customer wants or what the technology is capable of). The 
tollowing different types of requiremcius are often identified: 

Aircraft Functional Requirements: These requirements identify and describe the functions that 
must be pertormed to fulfill the aircraft operational requirements (i.e., those that have some 
identifiable flight deck impact). Each functional requirement consists of three components: (1) 
the generic function that must be performed; (2) the performance criteria which must be met; 
and (3) any constraints within which the function must be performed. An example of a 
functional requirement is to maintain the aircraft on the runway centerline during landing 
rollout, to within a certain number of feet of offset. 

Aircraft Operational Requirements: These requirements summarize the total effects of the 
combined mission, customer, flight crew, environmental, regulatory, and program 
requirements on the operational characteristics of the aircraft as a whole. The goal is to define 
aircraft operational requirements as what the aircraft needs to be able to do (from the skin out; 
i.e., without any consideration for who or what inside the aircraft is making it work), although 
in practice >me of these operational requirements recognize that high-level decisions have been 
implicitly made. For example, the operational requirement for the aircraft to be able to perform 
visual approaches and landings in visual meteorological conditions (VMC) presupposes the 
presence of a flight crew with access to the appropriate information and controls to make such 
approaches and landings. Due to practical limitations, the scope of the aircraft operational 
requirements considered in a typical flight deck design process is usually restricted to those 
requirements that have some identifiable flight deck impact. 

Aircraft System Requirements: These requirements specify the generic high-level systems that 
will be responsible for carrying out certain collections of aircraft functions. To the extent 
possible, design decisions concerning the allocation of aircraft functions to either humans or 
automated systems are deferred until later in the design process. For example, the flight deck 
as a high-level system is identified as being responsible for the function of maintaining the 
runway centerline during landing rollout. Whether humans or automated systems within the 
flight deck actually perform tasks which accomplish this function is not yet decided. 

Customer Requirements: These requirements are driven by the reality of the customer’s 
business, and reflect the necessary characteristics of the aircraft from an airline operations 
standpoint. Examples include such items as the minimum number of operating hours per day, 
the turnaround time between flights, the ease of pilot transition both into and out of the aircraft, 
and both initial purchase and recurring operational costs. 

Environmental Requirements: These requirements are driven by the need to limit the impact of 
the aircraft's operation on the surrounding environment. Examples include restrictions on 
where supersonic flight can occur, and limits on the amounts of combustion emissions by the 
engines into the upper atmosphere. 

Flight Crew Requirements: These requirements are driven by the need to account for the basic 
physiological and psychological limitations ot the humans who will occupy and operate the 
aircraft. Examples include oxygen and pressurization, radiation exposure levels, the effects of 
oscillation and vibration, and ingress and egress from the seating provided. 
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Flight Deck Requirements: These requirements describe what the different components of the 
night deck are, and which functions are allocated to each of these components. For the 
example ol maintaining the runway centerline during landing rollout, this function is allocated 
to both the flight crew (tor manual landings) and to the automated systems (for automatic 
landings). This case demonstrates that a single generic function may result in requirements 
placed on two different components within the flight deck. 

Mission Requirements: These requirements are driven by the general configuration of the 
aircraft itself and the mission it is expected to fulfill. Examples include cruise speed, range, 
payload capacity, and the ability to use existing runways, taxiways, and ramp space. 

Program Requirements: These requirements are driven by the airplane development program 
itself, and include general configuration and performance data and high-level decisions based 
on the aircraft manufacturer's internal Design Requirements and Objectives Document (or 
equivalent). Examples of the former include such items as length, wingspan, gear geometry, 
weight, and design cruise Mach number, and examples of the latter include subsystem and 
communications capabilities, no preferential ATC treatment, and a two-person crew. 

Regulatory Requirements: These requirements are driven by the need to operate successfully 
within the existing and future structure of U.S. and international airspace systems, and to 
comply with the regulations which govern their use. Examples include noise abatement 
P.^edures, speed restrictions and spacing compatibility with terminal area procedures, and the 
ability to operate in a mixed VFR/IFR traffic environment. 

Situation Awareness: The perception on the part of a flight crew member of all the relevant pieces of 
information in both the flight deck and the external environment, the comprehension of their effect on 
the current mission status, and the projection of the values of these pieces of information (and their 
effect on the mission) into the near future. 

Synthetic Vision: A method of supplying forward vision capability to the flight crew when forward 
windows cannot be used because of die fuselage geometry. 

Technology Constraints: These constraints are imposed by the expected state of advances in the core 
technologies required to implement a specific system based on the system specification. 

Test and Evaluation: This is defined here specifically as the process by which allocation decisions, 
design concepts, design prototypes, and the final integrated design are evaluated on the basis of how 
well they meet the design requirements and how usable they are from the flight crew perspective. The 
evaluation methods depend upon the stage of design: for example, allocation decisions and design 
concepts may be tested using pen-and-paper structured scenario walkthroughs, design prototypes may 
be evaluated using mockups or computer workstation experiments, and the final integrated design may 
be tested using a partial- or full-mission flight simulator. 

Top-down Approach. This is an approach to design which is driven by both a hierarchy of cascading 
requirements (e.g., operational, functional, systems) and a theoretically-based philosophy of what 
constitutes good design. 

u , The de P rce to which a desi 8 n exhibits the following five characteristics (from Nielson, 
1993). (1) leamability, in that it requires minimal training for proficient use; (2) efficiency, in that it 
allows a high rate of productivity once training is complete; (3) memorability, in that it requires 
minimal refamiliarization after a period of nonuse; (4) error reduction, in that it prevents errors as much 
as possible and allows for enr detection, correction, and tolerance when prevention isn’t possible; 
and (5) satisfaction, in that it p* tes the operators with a subjective feeling of satisfaction during use. 
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Utility. The degree to which the requisite functions, as determined by the appropriate requirements, 
are present and supported by the design. 

Workload: In the context of the commercial flight deck, workload is a multi-dimensional concept 
consisting of: ( 1 ) the duties, amount of work, or number of tasks that a flight crew member must 
accomplish; (2) the duties of the flight crew member with respect to a particular time interval during 
which those duties must be accomplished; and/or (3) the subjective experience of the flight crew 
member while performing those duties in a particular mission context. Workload may be either 
physical or mental. 


1.0 EXECUTIVE SUMMARY 


Past night deck design practices used within the U.S. commercial transport aircraft industry 
have been highly successful in producing safe and efficient aircraft. However, recent advances in 
automation have changed the way pilots operate aircraft, and these changes make it necessary to 
reconsider overall flight deck design. Automated systems have become more complex and numerous, 
and often their inner functioning is partially or fully opaque to the flight crew. This raises pilot 
concerns about the trustworthiness of automation, and makes crew awareness of all the intricacies of 
operation that may impact safe flight difficult to achieve. While pilots remain ultimately responsible for 
mission success, performance of flight deck tasks has been more widely distributed across human and 
automated resources. Advances in sensor and data integration technologies now make far more 
information available than may be prudent to present to the flight crew. The High Speed Civil 
Transport (HSCT) mission will likely add new information requirements, such as those for sonic 
boom management and supersonic/subsonic speed management. Consequendy, whether one is 
concerned with the design of the HSCT, or a next generation subsonic aircraft that will include 
technological leaps in automated systems, basic issues in human usability of complex systems will be 
magnified. These concerns must be addressed, in part, with an explicit, written design philosophy 
focusing on human performance and systems operability in the context of the overall flight crew/flight 
deck system (i.e., a crew-centered philosophy). This document provides such a philosophy, 
expressed as a set of guiding design principles, and accompanied by information that will help focus 
attention on flight crew issues earlier and iteratively within the design process. 

The philosophy assumes that the flight crew will remain an integral component of safe and 
efficient commercial flight for the foreseeable future because human skills, knowledge, and flexibility 
are required in the opeiation of complex systems in an unpre '• 'table and dynamic environment. The 
performance of the overall flight crew/flight deck system dejv .ds on understanding the total system, 
its human and automated components, and the way these components interact to accomplish the 
mission. The philosophy, therefore, seeks to elevate design issues associated with the understanding 
of human performance and cooperative performance of humans and automation to the same level of 
importance as the past focus on purely technological issues, such as hardware performance and 
reliability. It also seeks to elevate flight crew/flight deck issues to the same level of importance given 
other aircraft design areas, such as aerodynamics and structural engineering. The philosophy includes 
the view that flight deck automation should always support various pilot roles in successfully 
completing the mission. Pilot roles can be defined in many ways, but the philosophy suggests that it is 
importan. to identify human roles which highlight and distinguish important categories of design issues 
that can affect overall flight crew/flight deck performance. These roles are: pilots as team members, 
pilots as commanders, pilots as individual operators, and pilots as flight deck occupants. Design 
principles are presented according to these pilot roles. A framework for more detailed guidelines is 
presented which accounts for both pilot roles and different categories of flight deck features (i.e., 
displays, controls, automation, and alerts). 

This document is Part 1 of a two-part set. The objective of the document is to provide a 
description of the philosophy at a level that is aimed primarily toward managers. It is intended to: (1) 
establish a common perspective of crew-centered design, and the ways that perspective can be applied 
within the design process; and (2) provide a framework for developing increasingly detailed flight deck 
guidelines which are consistent with the guiding principles and philosophy statements. Part 2 of the 
document set will provide more detailed descriptions of design guidelines, test and evaluation issues, 
recommendations for how to apply the philosophy, and methods for identifying and resolving conflicts 
among design principles and among design guidelines. 
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This document provides guidance by describing good attributes of the design product, and 
characteristics of the design process that will facilitate their incorporation in future flight decks. It 
presents philosophy statements, guiding principles, and a framework for organizing design guidelines 
and it suggests where, within the design process, they should be applied. This should help introduce ’ 
fhght crew issues earlier and make them explicit and formal. It also describes test and evaluation 
(T&E) issues and methods. Evaluation, especially in the sense of operability or usability testing, 
throughout the design process, complements a crew-centered design philosophy. A good guiding 
philosophy alone can not assure good, human-centered design. Testing for usability is no*, a process 
that follows design; it is part ot design. Experts in the design of human-computer interfaces (e.g., 
Gould, 1988), emphasize early and continual user testing as a fundamental principle of system design. 
We consider it a fundamental element of a design process that will assure a crew-centered flight deck 
design. 

This crew-centered flight deck design philosophy is by no means a new concept or approach. 

It borrows heavily from previous research and practices in human factors and experimental 
psychology, and is consistent with all approaches which focus on facilitating how humans interact 
with their environment, tools, automation, and each other to improve overall performance of complex 
man-machine systems. This includes approaches such as human engineering (e.g., Adams, 1989; 
Bailey, 1982, Sanders & McCormick, 1993; Van Cott & Kinkade, 1972), cognitive engineering and 
engineering psychology (e.g., Helander, 1988; Norman, 1986; Rasmussen, 1986; Wickens, 1991; 
Woods & Roth, 1988), and human-centered automation approaches (e.g., Billings, 1991; Norman et 
al„ 1988; Regal & Braune, 1992; Rouse, Geddes, & Curry, 1987; Wilson & Fadden, 1991). In 
addition, work on developing specific philosophies for flight deck design has progressed recently both 
in the United States (e.g., Lehman, et al„ 1994; Braune, Graeber, & Fadden, 1991) and in Europe 
(e.g., Wainwnght, 1991; Hcldt, 1985; Hach & Heldt, 1984). 

"Hie crew-centered flight deck philosophy described in this document is based on the 
perspective that the flight deck is a complex system composed of equipment and the flight crew. The 
philosophy assumes that the flight crew will remain an integral component of safe and efficient 
commercial flight for the foreseeable future. While many accidents and incidents are attributed to "pilot 
error, these problems often arise due to specific design decisions. Further, it is our firm belief that 
the flight crew is the most critical component of the flight deck: human capabilities are absolutely 
mandatory tor safe operation of complex systems in an unpredictable and dynamic environment, and 
will be for the foreseeable future. We presume this is the fundamental rationale for the flight crew's 
ultimate legal responsibility for the safety of the flight. Also, the performance of the overall flight 
crew/flight deck system depends on understanding the total system, its human and automated 
components, and the way these components interact to accomplish the mission. The philosophy, 
therefore, seeks to elevate design issues associated with the understanding of human performance and 
cooperative performance ot humans and automation to the same level of importance as the past focus 
on purely technological issues, such as hardware performance and reliability. The philosophy includes 
the view that the flight deck automation and flight crew interfaces should support the flight crew in 
accomplishment of the mission. Automation may aid the pilot with information, augment the pilot by 
performing control actions, or substitute tor the pilot entirely in conducting some functions or tasks. 

But in each of these capacities, the automation should serve the flight crew. This is based on the fact 
that since pilots are ultimately responsible for the flight, they should always have final authority, and 
the information and means to exercise that authority. 

Pilot roles can be defined in many ways. This philosophy identifies human roles which 
highlight and distinguish important categories of design issues that can affect overall flight crcw/flight 
deck performance. The roles identified are: pilots as team members, pilots as commanders, pilots as 
individual operators, and pilots as flight deck occupants. The role of team member highlights design 
issues that affect communication, coordination, common functional understanding and resource 
management. The role of tcmmaodci highlights design issues that affect authority, responsibility and 
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the allocation of functions. The role of individual operator highlights traditional human factors design 
issues such as workload, anthropometries, task compatibility with human strengths and limitations, 
and interface design. The role of occupant highlights design issues such as comfort, health, safety, 
and subsistence. Although human/ nv° ' ine system performance is affected by a wide range of factors, 
including pilot training and procedures and organizational factors, this report presents a philosophy for 
design . It focuses on design as a mechanism for complementing human abilities and compensating 
for human limitations in the pursuit of overall flight safety, efficiency, and comfort. It does not cover 
purely technological issues such as hardware performance and reliability, human factors issues related 
to aircraft safety but specific to agents outside the flight deck such as air traffic controllers or company 
dispatchers, nor many other important issues affecting flight deck design, such as cost and weight. 


2.2 Users and Use of Document 

This document is Part 1 of a two-part set. The objective of Part 1 is to provide a high level 
description of the philosophy and its application to a generalized flight deck design process. Part 2 
will provide more detailed descriptions of design guidelines, test and evaluation issues, 
recommendations for how to apply the philosophy, and metnods for identifying and resolving conflicts 
among design principles and guidelines. Table 1 describes the users of this document and how the 
document supports their functions. 


Table 1. Intended users and uses of the document. 


Document 

User 

To Support 

By Mear r Of 

Part 1 

HSR managers 

High level program 
funding/focus decisions 

Informing, developing crew-centered 
design mind-set 


HSCT program 
managers 

High level design & 
resource decisions, 
formalize design process 

Informing, developing crew-centered 
design mind-set, institutionalizing 
ideas 


FAA managers 

Certification planning 

Informing, developing crew-centered 
design mind set 


Airline managers 

Profitability & 
operability determination 

Informing, developing crew-centered 
design mind-set 


Airline pilots 

Operability assessment 

Informing, developing crew-centered 
design mind set 

Part 1 & 2 

HSR researchers 

Design concept & 
prototype development, 
research issue 
identification, evaluation 

Providing guidance, identifying 
research issues through conflict 
resolution, and providing test & 
evaluation (T&E) methods 


HSR engineers 

Requirements 
development and design 
concept and prototype 
development 

rtoviding rationale & guidance for 
writing & checking requirements & 
concepts through use of guidelines 
and T&L methods 


HSCT night deck chief 
engineer & chief pilot 

Major flight deck design 
decisions 

Providing guidance in making 
important flight deck design 
decisions by using guidelines and 
conflict resolution methods 


HSCr lead designers 

Low level design 
decisions 

Providing guidance in selecting 
design alternatives that embody 
"good design practice" through use of 
guidelines & conflict resolution 
methods 
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This document: (1) establishes a common perspective of what crew-centered design is, and 
where within the design process it should be applied; and (2) provides a framework for developing 
increasingly detailed flight deck design guidelines which can be supported by reference to specific 
guiding principles and philosophy statements. The primary users of the document are managers, 
engineers, and researchers within NASA's HSR program. Secondary users are similar users within 
an HSCT airplane program and other participants within the industry that will have a role in design 
through their interaction with the airplane program, such as Federal Aviation Agency (FAA) and airline 
personnel. The better these participants understand a crew-centered design philosophy, the better 
equipped they will be to contribute to the design process within the context of their specified roles. 

For example, to the extent that certification is part of the process of assuring the "goodness" of design, 
if FAA certification pilots understand crew-centered issues from the design perspective, and certify by 
means similar to test and evaluation used throughout the design process, then perhaps certification of 
the flight deck could be a more standard, expedient, and cost-effective process. 


2,3 Organization of the Document 

The remainder of this report is divided into four main sections (Sections 3-6), and three 
appendices (Appendices A-C). Section 3 describes the design process, and where within that process 
the philosophy should be applied. Section 4 describes the actual philosophy, guiding principles, and a 
framework for crew-centered design guidelines, and begins to address how conflicts among principles 
and guidelines might be identified and resolved. Section 5 provides concluding remarks, and Section 
6 provides references. Appendix A describes test and evaluation issues, including a representative 
sampling of tools and methods for evaluating the operability or usability of design concepts. Appendix 
B lists the working assumptions about the HSCT environment and aircraft currently listed by the HSR 
program. Appendix C identifies resource materials that can be used to find sources for more details on 
issues described in this document. It includes a compilation of many standard sources of relevant 
design guidance. 

Part 2 of this document set will be developed within the next two years. It will include a more 
extensive collection of design guidelines. It will provide more detailed information on how to apply 
the principles and guidelines to flight deck design. It will also elaborate on tools and methods for 
measuring the effect of design decisions on flight crew/flight deck performance earlier in the design 
process. A more detailed review of issues relative to identification and resolution of conflicts and 
contradictions among principles and guidelines will also be provided. A large database of relevant 
studies and materials will be compiled to serve as the rationale for design decisions which can be traced 
through the guidelines and principles. Research issues related to the crew-centered design philosophy 
will be identified. 

Various users of the philosophy document may have quite distinct perspectives of and 
vocabularies for design issues of interest. One method that will be pursued to provide multiple access 
and retrieval paths for the philosophy statements, principles, and most importantly, the guidelines, is 
an electronic hypertext version of the document. This electronic version could include the relevant 
links between the top-level philosophy statements, the guiding principles, and the various guidelines, 
so that the justification and rationale for each principle or guideline category can be traced back to the 
fundamentals of the philosophy itself. The initial method planned for allowing multiple access 
methods will be to create access paths for: (1) HSR program managers and researchers and others 
interested in the supporting documentation and theoretical rationale behind principles that are structured 
by pilot roles; and (2) systems requirements writers and system designers that arc based on the flight 
deck features that arc used to organize the design guidelines. These two different sets of access paths 
should allow the different types of users to quickly retrieve the information they need using their own 
perspective and vocabulary. 
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3.0 DESIGN PROCESS 


2J — The Overa ll Design P rnrow 

by , W ^° mmercial 018,11 ^ Signed is complex, largely unwritten 

vanable, and non-standard. The process is also overly reliant on the knowledge and exSnces of 

individuals involved in each program. That said, Figure 1 is an attempt to describe this process- it 
represents a composite flight deck design process based on various design process materials that have 
been generated within, or provided to, NASA's HSR program. Although the figure is not intended to 
exactly represent the accepted design process within any particular organization or program it is meant 
obedescnptive of accepted design practice. Definition of the terms used in the figui/are included in 
the glossary. Note that the figure is purposely oversimplified. For example, the hox labeled "Final 
Integrated Design encompasses an enormous number of design and evaluation tasks, and can take 
years to accomplish. It could be expanded into a figure of its own that includes not only the conceptual 

bU ‘ 8150 S,mUlaU0 ' K ' nigltt tes,s - ‘X'Mna™ »<■ 



Figure 1 . Simplified representation of the flight deck design process. 


iHp ^ t crew-centered design philosophy presented in this document should affect 
the design process in a number of places, which will be described in the next section. It is also 
important to note that we believe the philosophy has implications for the design process itself For 

^irfo^fn h r 0S ? Ph H y e 7 h f sizes lhal total fli8ht crew/flight deck performance is more important 
than performance of individual components, suggesting that flight deck integration issues should be 
addressed prior to, or in parallel with, development of individual flight deck systems or components 
e.g synUrette vision system for the HSCn This appears to be contrite the wTy flighXk^ 
raditionally designed. However, the inclusion of integration issues before systems are completely 
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specified is difficult. Also, while the philosophy includes a set of principles pertaining to the flight 
deck as a product of design, it could also include principles of the design process. For example, we 
could easily envision a principle stating that flight deck design, particularly issues pertaining to flight 
crew operability, should be addressed as early as possible and with as many resources as other aircraft 
design areas, such as propulsion, structures, and noise. Other "crew-centered" principles of the 
design process, such as "simplify before automating," "perform pilot-in-the-loop evaluations early in 
design," and "test the comers of the human performance envelope in evaluating man-machine 
systems," could also be generated. While some of these design process issues will be discussed under 
other sections, generally, recommendations of ways that the design process should be changed to be 
consistent with a crew-centered design perspective is beyond the scope of this document. Several 
resources in Appendix C address these issues. 

One particularly important aspect of the design process from the perspective of a crew-centered 
philosophy is test and evaluation. Design changes are most costly once installed in an operational 
environment. The earlier in the design cycle that problems and poor design decisions can be caught, 
the more easily and cost-effectively changes can be made. Fully understanding and applying an 
explicit crew-centered philosophy of design to highlight issues and potential design solutions that 
affect flight crew/flight deck performance is one way good design can be assured early in the design 
cycle. But because the philosophy cannot be comprehensive and completely unambiguous, there is no 
guarantee that a design which adheres to it will be good in every aspect. Hence, a second aspect of 
crew-centered design is iteratively testing and evaluating preliminary concepts, with an emphasis on 
pilot-in-the-loop evaluations, as an integral part of design. Adherence to the philosophy and specific 
guidelines and requirements will assure a relatively good design, but test and evaluation provides the 
final calibration (since aircraft systems are so complex, certification and line operation will for the 
foreseeable future continue to provide the final usability testing). Many test and evaluation tools, 
methods, and evaluation platforms are available. Appendix A provides more details about test and 
evaluation, especially concerning aspects that are relevant to advancing a crew-centered perspective of 
flight deck design. 


3,2 Where to Apply the -Philosophy 

One of the stated goals of this document is to help establish a common perspective among the 
different researchers and managers participating in the HSR program with respect to the importance of 
a design philosophy focused on the flight crew. Part of that perspective is where the implementation 
of this philosophy is addressed in the design process. In the past, since a design philosophy and a 
design process have been largely unwritten, the application of a philosophy to a design process has 
necessarily been informal and non-standard. 

Figure 2 depicts where we believe the philosophy should impact the design process depicted in 
Figure 1. The philosophy and its impact are shown with double lines to illustrate that this is 
prescriptive information based on the views of the authors. As described in the footnotes at the bottom 
of the figure, there are some very important points to make about where the philosophy affects the 
design process. First, the philosophy should affect any step or stage of the design process where 
design decisions are made. For example, in an idealized process, airrlane functional requirements may 
strictly include only generic functions required of the aircraft to operate within the mission 
environment, and thus should he affected minimally by crew issues such as function allocation, 
interfaces and levels of automation. If functional requirements are not developed in this "pure" sense, 
that is, they include flight deck functional requirements and/or function allocation decisions, then 
design decisions are made implicitly within the process of developing functional requirements and the 
philosophy should affect those design decisions. Second, although the philosophy is most commonly 
applied to "how to” decisions in selecting design concepts that meet various requirements (i.e., the 
boxes labeled initial design concepts and final integrated design), crew issues can also affect the 
"what” of design, that is, what the aircraft or the flight deck must do, operationally or functionally. 
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While the number of crew issues that can affect the operational and functional "what" may be small 
compared to those that affect the "how to," especially at the aircraft level, they are important Obvious 
examples include habitat issues that affect aircraft operational requirements such as the need to prevent 
bodily injury and preserve the health of the inhabitants of the aircraft. We believe that there are other 
crew issues that affect hard operational requirements as well. For example, since the flight crew is 
responsible for critical flight functions which require the pilots to perceive and respond to the external 
environment, operational requirements exist for the aircraft to fly manual approaches and to follow 
"see and avoid" procedures. While many of these crew-driven requirements overlap with regulatory 
and other requirements, we believe thai acknowledging the impact of crew-related issues such as the 
necessity of manual flight, minimum flight deck size, and external vision requirements on the operation 
of the aircraft may highlight conflicts with other constraints and requirements much earlier in the 
design process. 


Previous Design, 
Production, and 
Operational Experience, 
^Technology Constraints 


External 
Requirements (Mission, 
Customer, Flight Crew, 
Environmental, 
egulatory, Program 



Aircraft 


Aircraft 


Aircraft 

Operational 


Functional 


System 

Requirements 


Requirements 


Requirements 


Test and 
Evaluation 




Philosophy may affect 
Philosophy definitely affects 


ther Systems 
Requirements 


lother Systems 
| Initial Design 
Concepts 



Notes: (11 Philosophy should etlect design process wherever design decisions are explicitly or implicitly made 
For example, aircraft operational and functional requirements should be independent of design 
decisions, but often they are not. function allocations, pilot interfaces, and flight deck 
requirements are sometimes involved, 

(2) Philosophy should affect the operation or function of the aircraft if pilot roles dictate that the 

aircraft interact with the outside environment in certain ways (e g., must be able to perform 
a visual approach or manual landing because the pilot has ultimate authority over critical flight 
functions) 


Figure 2. Impact of philosophy on design process. 


Generally, we believe the influence of a crew-centered design philosophy should be explicitly 
applied earlier in the design process than is often acknowledged. Right deck design is a complex and 
amorphous process; design decisions, trade-offs, and resolution of conflicting constraints and 
requirements often arc made implicitly and early. If crew issues arc not considered early, then design 
concepts can be carried forward and major usability implications not discovered until they are very 
costly to isolate and change. Early introduction of crew issues makes explicit that the philosophy, in 
part, includes requirements or constraints analogous to requirements from other sources. In addition. 
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the process of translating the philosophy into requirements, design decisions and design concepts is ill- 
defined. The current understanding of human behavior necessitates that much of the design guidance 
be soft rather than hard. The applicability of guidelines often depends on contextual factors; there are 
many situations in which they must be overridden by some other consideration. Hence the philosophy 
does not always translate into hard, quantifiable, requirements. This is why crew-centered principles 
and guidelines are more often applied as general guidance in the "how to" of the design process rather 
than as hard requirements. 
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4.0 THE PHILOSOPHY 


The crew-centered flight deck design philosophy presented here begins with the explicit 
acknowledgment that the flight crew, flight deck, and even the airplane itself are only parts of a much 
larger commercial air transportation system. Other elements of this system include the airlines and 
their flight dispatchers and maintenance personnel, weather forecasters, airport operators, air traffic 
controllers, and government regulators. Mission success is the overall goal, and it depends upon the 
cooperation and performance of each of these elements. Within this context, however, the philosophy 
contained in this document is limited to the operation of the aircraft by the flight crew. Because human 
skills, knowledge and flexibility are, and will continue to be, required in the operation of complex 
systems in the dynamic and often unpredictable aviation environment, flight deck design should be 
crew-centered in the sense that it should support the flight crew in successfully accomplishing the 
mission. 

The crew-centered design philosophy espoused here can be described in its simplest form with 
the following set of Philosophy Statements: 

S - 1 . Each design decision should consider overall flight safety and efficiency. Combined flight 
crew/flight deck system performance is more important than local optimization of the 
performance of any human or automated component in that system. 

S-2. Overall flight crew/flight deck performance and the performance of the human and automated 
components are affected by qualitatively different sets of issues depending on the specific 
operational roles in which pilots are viewed. Flight deck design should consider these different 
roles. 

S-3. Humans and machines are not comparable, they are complementary (Jordan, 1963); that is, 

they possess different capabilities, limitations, strengths and weaknesses, and there is a mutual 
dependence required between humans and machines to successfully accomplish the mission. 
Safety and efficiency of flight will be maximized by focusing on ways to develop and support 
the complementary nature of the flight crew and the flight deck systems. 

This philosophy is embodied in the following sections, which describe performance objectives, 
pilot roles, principles, guidelines, and issues related to resolving conflicts among principles and 
guidelines. The organization of the principles is detei. lined by the various roles of the flight crew 
members, as described below. The pilot roles also influence the organization of the categories of 
design guidance. 


4J Performance Objectives 

The general relationship between aircraft mission objectives, flight crew/flight deck 
performance objectives, and flight crew and automation roles is depicted in Figure 3. The mission is 
to transport both passengers and cargo from the departure to the arrival airport, and the objectives, in 
order of importance, are to do this with safety, efficiency, and passenger comfort (although passenger 
comfort may outweigh efficiency in certain cases, such as avoiding turbulence at the expense of a less 
efficient cruise altitude). The goal of the crew-centered philosophy is to help in the design of a flight 
deck which assists the flight crew in accomplishing mission objectives. Mission success depends on 
overall performance of the system formed by the flight crew and flight deck automation. The 
philosophy suggests that overall performance of the flight crew/flight deck system is best served by 
prescribing specific roles (not tasks) to the automation that support specific roles of the flight crew. 
Defining the roles of the flight crew is useful in categorizing design principles as a way to highlight 


different sets of crew issues. The test and evaluation measures by which flight crew/flight deck 
performance are assessed are shown at the bottom of Figure 3. and are described in Appendix A. 



Efficiency 

r~ 


Passe nger 
Comfort 



Objective of Crew-Centered Flight Deck Design 
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Figure 3. The relationship between mission objectives and performance objectives. 


4*2 Eilat .Rotes 

The organizing scheme used for the generation and presentation of the guiding principles is 
based upon the role of pilots as team members, the role of pilots as commanders, the role of pilots as 
individual operators, and the role of pilots as flight deck occupants. These roles are nested rather than 
independent. That is, the pilot is always an occupant, and is an operator while in the roles of 
commander and team player. Thus, there will be some overlap in design issues related to the different 
roles. But we believe these roles highlight and distinguish important categories of design issues that 
can affect human performance and overall flight crew/flight deck performance. 

With the complex systems, technologies, and operating environments that characterize modem 
commercial aviation, how humans work with other "agents,” human and automated, (e.g., in 
communication, coordination, and allocation of functions) is a major design issue. The birth of 







S?rH ? n * esource Man agement (CRM) was due to the realization that problems in communication and 

Ste SS n? W mCmberS were c . ontnbuting factors in a large number of accidents and 
incidents. Problems of commumcauon and coordination are not limited to between crew members 

miscommuiucauons between flight crew and air traffic controUers have been well documented h 
Aviation Safety Reporting System incident reports. Further, automation "surprises" reflecting Dilot 
misunderstandmg of automated systems such ks the flight management sysSaSSS 
are well documented (Sarter & Woods, 1992). The team member role addresses these issues While 
authority issues and the role of commander could be covered under the role of team member we felt it 

? C i?ii U °? se S a,d y because of ^ significance of authority issues in defining the 
human-centered philosophy. There is strong consensus that the pilot will continue to be ultimately 

KS5 S ii le for sale operation of the aircraft (e.g., Billings, 1991; Wilson & Fadden, 1991) and this 
shouW be a primary dnver of funcuon allocation decisions. Supporting the pilot as an individual 
operator is the pnmary focus o. most current human factors guidance - design must account for all 
that is lenown about how humans perform tasks. The role of occupant 

t0 t0r k et must support the pilot in more than the obvious mission functions- 

there are peripheral tasks and pilot needs that must be supported in the context of the pilot as a human 
occupying a specific environment for a period of time. Each of these roles is described below: 

Pilots as Team Members: This reflects the role of pilots as members of a team that includes not 
only the other flight crew members, but also elements of the flight deck automation and in the 
larger context, elements of a distributed system including air trifle controUers airline disDatch 
regulatory agencies, etc. The issues involved include the need for communication, 

aocompli^h n tasks funCtional understandin g among all team members to successfully 

Pilots as Commanders: This reflects the role of each pilot, individually, as being directly 
responsible for the success of the mission. The issues involved include the level of pilot 
authority over the flight deck automation, and the ability of the pilot to delegate tasks! 

Pilots as Individual Operators: This reflects the role of pUots as individual human operators 

rT ° f C , 0ntr0lS diSplayS ’ ^ issues invo,ved ‘"cLe many 
ot the ti-aditional human factors disciplines such as anthropometries, conti ol/display 
compatibility, and cognitive processing. F y 

rcfkcls f* r * i Je.pnots as living organisms wiihin the flight 
JhP S ? \ \ ^ L ,nv ?. lved include mgress and egress capability, protection from 
the radiauon and atmospheric conditions at the expected cruise altitudes, seating, fighting and 

accommodation of items such as food and drink containers. «g, ugnung, ana 

° f °n 8an 5' ing ^ gu i din S Principles according to the pilot roles identified above in the 
context of the overaU performance objectives framework, is that it serves as a bridge into the 
supporting research literature on human factors and flight deck design; we believe that the roles 
repent drstmedy diffenem design concerns and issuS. The pilotmiS *™e « one of Se 
dimensions by which the design guidelines are categorized. 


4u2 — Automation Roles 

As stated earlier, and as depicted in Figure 3 above, the philosophy suggests that overall 

msksfmTh? ° , the ^ 18ht £ rew/nighl deck s y ste m is best served by prescribing specific roles (not 
tasks) to the automation that support specific roles of the flight crew. In this sense the automation is 
always subservient to the flight crew. It may substitute for the pilot entirer^dS^e 

functions and tasks, it may augment the pilot by performing certain control actions or it mav aid the 
pilot in gathering and integrating information. y d the 
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4»4 Design Principles 

A fundamental purpose of constructing a set of principles to represent a philosophy, as defined 
in Section 4.0, is for these principles to serve as practical guides and not merely abstract concepts. 

The difficulty of accomplishing this balancing act between the practical and the abstract has long been 
recognized in many fields. For example, in his classic work on strategy the military writer B.H. 
Liddell Hart ( 1967) observed that: 

“... the modem tendency has been to search for principles which can each be expressed in a 
single word - and then need several thousand words to explain them. Even so, these 
‘principles’ are so abstract that they mean different things to different men, and, for any value, 
depend on the individual’s own understanding... The longer one continues the search for such 
omnipotent abstractions, the more do they appear a mirage, neither attainable nor useful - 
except as an intellectual exercise.” 

This document therefore strives to present the principles in a form that will result in consistent 
interpretations, even though this may result in less elegance in phrasing. The principles are listed 
below according to the pilot roles described above, and are numbered as PT-x, PC-x, PI-x, or PO-x, 
for principles related to the roles of team member (PT), commander (PC), individual operator (PI), or 
flight deck occupant (PO). 


4.4.1 Pilots as Team Members 

» PT - 1 . The design should facilitate human operator awareness of his or her responsibilities, and 

the responsibilities of the other human operators and automated flight deck systems, in 
fulfilling the current mission objectives. 

The flight deck design should ensure that each pilot remains aware of who or what system has 
been allocated, and is actually performing, which functions or tasks. In addition, the human operators 
should be well acquainted with the functional capacities of automated flight deck systems. This 
heightened level of awareness of responsibilities and capabilities should help to prevent the problem of 
"nobody minding the store,” which was a contributing factor in the December 29, 1972 Eastern 
Airlines Flight 401 nighttime crash into the Florida Everglades near Miami. In this accident, the flight 
crew became distracted while diagnosing the status of a gear indicator light on the flight deck of the 
Lockheed L- 101 1 , and didn’t notice that the autopilot had been inadvertently disconnected and was 
allowing the aircraft to gradually descend. 

PT-2. The design should facilitate the communication of activities, task status, conceptual models, 
and current mission goals among the human operators and automated flight deck systems. 

The flight deck automation should be designed to actively inform the crew of what it is doing, 
how, and why, both to foster communication and to support the pilot's role as commander in 
determining whether intervention is necessary. This includes feedback concerning mode status and 
human- or automation-initiated mode changes ("pre-programmed" pilot inputs may result in mode 
changes that appear to be automation-initiated). For example, the specific operating modes of the 
autofiight system need to be unambiguously distinguishable to help prevent accidents such as the 
January 20, 1992 Air Inter crash near Strasbourg, France, in which the Airbus A-320 flight crew is 
believed to have mistakenly selected a 3,300 feet per minute vertical descent rate instead of a 3.3 
degree descent angle. Because the HSCT could have even more complex autoflight modes than 
modem conventional aircraft, communication of modes and autoflight system status may be even more 
important. The automation should also, to the extent possible, observe human operator actions and 
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changes in aircraft state to infer the current goals, procedures, and tasks in progress. This could be as 
simple as automatically displaying the checklists associated with active caution and warning messages, 
or as complex in the future as monitoring crew inputs to suggest better ways of accomplishing a given 
task. In addition, the flight deck design should support procedures and tasks which foster 
communication among the flight crew members and aiding systems. 

PT - 3 . The design should support the dynamic allocation of functions and tasks among multiple 

human operators and automated flight deck systems. 

The flight deck should be designed to facilitate the appropriate decomposition and dynamic 
allocation of tasks. One example of how this is done in current aircraft is the separation of the 
autoflight system functions into speed and directional control, so that the flight crew can easily choose 
to maintain manual control of the aircraft’s flight path while delegating speed control to the 
autothrottles, instead of being forced into an “all-or-nothing” use of the autopilot. The goal is to make 
sure that such allocations of functions are possible, and can be performed quickly, easily, and 
unambiguously by the flight crew. 

PT-4. The design should assure that team limitations are not exceeded. 

Flight crew members working as a team are subject to fundamental group dynamics and human 
limitations that affect their performance. For example, teams often suffer from group biases in 
problem solving, conflicts in personality, and differences in leadership styles. Some of these issues 
have recently been addressed by the airlines in the form of Crew Resource Management (CRM) 
training. However, the flight deck designer should also acknowledge and accommodate such 
limitations, and should recognize that similar limitations often exist when the flight crew and automated 
systems work together as a team. For example, designers need to be aware that if caution and warning 
displays present information about the potential underlying cause of a subsystem malfunction in an 
inappropriate manner, the flight crew may be induced to fixate on the proposed diagnosis (which may 
be uncertain) to the point that they fail to consider other possibilities. 

PT-5. Cooperative team capabilities (e.g. use of collective resources and cooperative problem 
solving) should be used to advantage when necessary. 

Just as the pilots as a team have inherent limitations, they also have inherent strengths. These 
include such capabilities as brainstorming and cooperative problem solving. It is not the case that 
design should require the use of such abilities; rather, it is important for the designer to recognize that 
these strengths exist and that they should be used to maximum advantage when necessary. Similarly, 
the complementary nature of the flight crew and the automated systems should be used to advantage 
when they work together as a team. 

PT-6. The design should minimize interference among functions or tasks which may be 

performed concurrently by multiple human operators or automated flight deck systems. 

The design should assure that attentional, mental processing, or physical conflicts do not arise 
when multiple flight crew members or automated systems are performing tasks concurrently. For 
example, the monitoring required of an automated system while it is performing a task should neither 
usurp the flight crew’s attention nor interfere with other tasks that the flight crew may be performing. 

PT-7. The design should facilitate the prevention, tolerance, detection, and correction of both 

human and system errors, using the capabilities of the human operators and the flight deck 
automation. 

The primary concept represented by this principle is that the humans and automated systems on 
the flight deck work in concert to assure that no one human mistake or system failure alone will cause a 
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catastrophic event to occur. The fact that mistakes and failures will indeed occur is acknowledged 
explicitly; the goal is to provide error avoidance techniques, redundancy and error cross-checking 
among team members such that those mistakes and failures are either prevented, or tolerated, trapped, 
and corrected before they have catastrophic consequences. In addition, the designers should ensure 
that flight crew actions which may be inadvertent errors are reversible, and that the flight deck design 
doesn't obscure, compound, or exacerbate the presence or effects of mistakes or failures. In some 
cases, failure detection and correction may be required so quickly that a purely human response is not 
possible. For example, it is anticipated that a condition such as engine unstart on the HSCT will need 
to be managed automatically because the inherent instability of the aircraft requires correction more 
quickly than could be achieved by the flight crew. 


4.4.2 Pilots as Commanders 

PC - 1 . The human operator should have final authority over all critical flight functions and tasks. 

The pilot is directly responsible for the safety of the aircraft, and given today's technology, 
safety is enhanced in a complex, dynamic environment if humans make final command decisions. 

This fact indicates that the pilot should be able to manually intervene in any function or task which is 
potentially critical to the safety of the flight. This may involve having active control, override 
capability, or the ability to command different levels or modes of automated operation. For example, 
the Full Authority Digital Engine Controllers (FADEC’s) on some current-generation aircraft have the 
authority to permanently shut down an engine, without flight crew override capability, when the 
controller determines that continued operation may damage the engine. The risks of taking this 
authority away from the flight crew were clearly demonstrated by the May 5, 1983 Eastern Airlines 
Flight 855 emergency landing at Miami International Airport after maintenance personnel forgot to 
replace the engine oil seals on all three engines of the Lockheed L- 10 1 1 . In this case, the crew 
successfully restarted the engine they had previously shut down due to oil starvation after the other two 
engines flamed out (also due to oil starvation). A modem FADEC would have prevented the engine 
from being restarted, which may have resulted in a forced ditching of the aircraft at sea. For the 
HSCT, a major implication of this principle is that the requirement to see and avoid other aircraft when 
flying under visual meteorological conditions (VMC) dictates that the pilots must "see" in front of the 
aircraft. If forward windows cannot provide this capability because of fuselage geometry, some other 
means of forward vision must be supplied. 

PC - 2. The human operator should have access to all available information concerning the status of 

the aircraft, its systems, and the progress of the flight. 

Pilots should be able to access any available information that they believe is critical to safe 
flight. All information useful during normal operations should be continuously displayed or readily 
available, and any specialized information that might possibly be useful for detailed problem-solving 
should be accessible. No sources of flight control information should be purposely withheld from the 
crew during flight. For example, detailed subsystem information that is normally only used for 
maintenance, but which under rare circumstances has implications for real-time operation, should not 
be withheld from the pilot, even if no checklists or procedures explicitly call for its use. Accidents 
such as the July 19, 1989 United Airlines Right 232 loss of all three hydraulic systems on a 
McDonnell-Douglas DC- 10 illustrate that unanticipated failure modes do indeed occur, and that 
withholding available and potentially useful information from the flight crew may be imprudent. 

PC -3. The human operator should have final authority over all dynamic function and task 
allocation. 

Because the pilot is responsible for safety, and current automation is not capable of perfectly 
assessing pilot intent or the external situation, the pilot should have the final authority over dynamic 
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function allocation. The automation should not be able to assign functions or tasks to the pilots, nor 
refuse to perform a function or task assigned by the pilot unless it is unable to do so. It should also 
not be able to take tasks or control away from the pilot without the pilot’s approval. For example, 
automation must not take a task from the pilot's control without consent simply because it detects that 
the pilot is in a high workload condition. Likewise, stick-pushers (systems which automatically 
engage to decrease the angle-of-attack of the aircraft when it is close" to stalling by pushing forward on 
the control column) and other automated devices must not use control forces which exceed the pilot’s 
ability to override them if necessary. It is acknowledged that the issue of dynamic function allocation 
is controversial. There are many advantages of automated dynamic function allocation and adaptive 
aiding (e.g., see Rouse, 1994), such as management of pilot workload and task involvement (e g 
Parasurammi. 1993; Pope, Comstock, Bartolome, Bogart & Burdette, 1994). If the complexity and 
predictability of system operation, from the operator's perspective, can be kept within acceptable 
limits, then perhaps automated dynamic function allocation will become more viable on future flight 

PC -4. The human operator should have the authority to exceed known system limitations when 
necessary to maintain the safety of the flight. 


Since certain actions can cause physical damage to aircraft systems and components but can 
under some circumstances, save die aircraft from a catastrophic event, the pilot should be able to 
exceed knowr. physical damage limitations if he or she determines it is in the interest of overall safety 
In some cases, such as the February 19, 1985 China Airlines Boeing B-747 inflight upset and 
uncontrolled descent over the Pacific Ocean, permanent structural damage may result from the 
subsequent recovery maneuvers which save the aircraft. Other times the crew actions may only result 
in shortening the operating life of a component, such as exceeding the rated temperature limits of the 
engines to get extra thrust during a windshear encounter. In both types of situations the crew may 
exceed known limits and damage the aircraft, but in doing so may prevent a fatal crash. 


4.4.3 Pilots as Individual Operators 

PI" 1 * Tte human operator should be appropriately involved in all functions and tasks which have 
been allocated to him or her. 

Because situation awareness relies to some degree upc.i the operator being actively involved, 
^Spcrs must make sure that the level of engagement of the human operator is appropriate for all 
cnUcal flight functions and tasks for which he or she is currendy responsible (based on the allocation 
of funcuons and tasks determined by the human's role as commander), if automation performs critical 
flight tuncoons for which the pilot serves as a backup, a level of involvement must be maintained 
under normal ce iditions such that the pilot is prepared to take over the function under non-normal 
conditions. For example, in the previously mentioned China Airlines B-747 incident in 1985, the 
flight crew was unaware of the acdons of the autopilot as it compensated for the adverse yaw created 
by a flameout on the number 4 engine. When the autopilot reached the limits of its control authority 
and disengaged itself, the flight crew was unprepared to resume manual control and the aircraft rolled 
over id began an uncontrolled descent 

PI*2. Different strategies should be supported for meeting mission objectives. 

Different environmental, operator, and task factors may require that certain mission objectives 
be met using different approaches, solution paths, and automation levels. The designers need to make 
sure that the procedures and automation options available to the human operator are not so rigid that 
only one strategy exists for fulfilling each goal or accomplishing each function or task. For example 
the level of automation appropriate for a function or task may depend on pilot workload: Lower 
automation levels (e.g., information aiding) may be more appropriate in lower stress/workload 
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situations, whereas very high stress/workload situations may require more automated assistance. 
Further, the population of potential human operators for any aircraft contains individuals with widely 
varying levels of operational experience, piloting skill, and cognitive style. The design of die flight 
deck must take these differences into account, and not rely on a single definition of an "average" or 
“worst case” pilot. 

PI- 3. The content and level of integration of information provided to the human operator should 
be appropriate for the functions and tasks being performed and the level of aiding or 
automation being used. 

The information provided to the human operator should represent the correct level of 
processing and integration of the raw data necessary to permit effective task performance. Although 
hum an operators often exhibit better performance when they are able to operate perceptually using their 
manual skills and procedural knowledge, deeper reasoning may be required and the information to 
support such reasoning may require substantially different levels of abstraction or integration than what 
is appropriate for other tasks. Raw data should be available for confirmation of processed 
information. An example of how important it is for the level of information integration to be 
appropriate to the task is the failure of the flight crew to recognize insufficient engine thrust during 
takeoff in the January 13, 1982 Air Florida Right 90 crash into the 14th Street Bridge in Washington, 
DC. In this case, the primary thrust-setting parameter was giving a false reading due to an iced-over 
sensor probe on the Boeing B-737, but all other engine instruments correctly indicated that insufficient 
thrust was being generated. Abbott (1989) demonstrated in a simulator experiment that better 
integration of the engine parameter data in a manner appropriate to the task may have prevented this 
accident. For the HSCT, the potential need for a synthetic vision system raises several questions 
associated with this principle. For example, "how much processing of sensor data should be done 
before it is presented to the pilot?" "How should synthetic vision information be integrated with other 
primary flight information?" "How should synthetic vision information be different depending on 
whether it is used for active flight control or passive monitoring of the autopilot?" 

PI- 4. Methods for accomplishing all flight crew functions and tasks should be consistent with 
mission objectives. 

The procedures and tasks of the human operator should make sense in terms of the mission 
objectives, and should flow together in a logical order. For example, the human operators should not 
have to "trick" the flight deck systems into performing a desired function, such as entering false winds 
aloft to move the top of descent point. 

PI - 5. Procedures and tasks with common components or goals should be performed in a 
consistent manner across systems and mission objectives. 

The procedures and tasks that the human operator performs should be consistent when the 
goals are comm n, so that a specific action does not have a completely different meaning or effect 
depending on the current task or system state. For example, methods of disengaging the autothrottle 
or autopilot should be consistent across autoflight modes. Failure to adhere to this principle may have 
been partly responsible for the April 26, 1994 China Airlines Right 140 crash at Nagoya International 
Airport in Tokyo, in which the flight crew of the Airbus A-3(X)-6(X)R inadvertently activated the 
go-around mode and was unable to disengage the autopilot using the common technique of manually 
displacing the control wheel (since this method of disengaging the autopilot is inhibited in the 
go-around mode). The autopilot then used its horizontal stabilizer trim authority to counteract the flight 
crew’s control inputs, which created an unsafe trim condition of which the crew wasn’t aware. 

PI- 6. Procedures and tasks with different components or goals should be distinct across systems 
and mission objectives. 
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procedures and tasks that the human operator performs should be distinct when the goals 
are different, so that unique actions are required to generate different effects. One example of how this 
principle can be applied is the autoflight system interface of the McDonnell-Douglas MD-1 1, in which 
making a speed, heading, or altitude intervention while the autopilot is engaged (by turning a knob) 
with the goal of departing the current steady-state value, requires a distinctly different control input 
than invoking the respective hold mode (by pressing a knob), with the goal of halting a transition in 
progress. An HSCT issue related to this principle involves the flight control inceptor (wheel and 
column, center stick, or sidestick): since it is likely the flight control laws will be different from 
conventional subsonic aircraft, should the control inceptor be distinctly different than those used on 
previous aircraft to reinforce the fact that the underlying operation is different? 


The design should facilitate the development by the human operator of conceptual models 
ol the mission objectives and system functions that are both useful and consistent with 
reality. 


determines, to a significant extent, how the human operator develops conceptua' 
models ol the flight deck systems and automation and why they work the way they do. Designers 
should explicitly recognize this fact, and facilitate the development of conceptual models that are both 
useful (i.e., they are developed to an appropriate level of detail and support appropriate behavior with 
regard to the system), and consistent with reality (i.e., they do not create misunderstandings about 
what the system is capable of doing and how it does it). For example, flight crews on many current- 
generation aircraft have had difficulty understanding some of the relationships between the various 
speed and vertical control modes of the autoflight systems, as evidenced by the large number of 
deviations from assigned altitudes detected and reported. In the case of the Boeing B-747-400, the 
mode annunciators on the primary flight display are organized by the autothrottle, roll, and pitch 
control portions of the autopilot, while the mode control panel is organized according to the speed, 
horizontal path, and vertical path interventions. Since both speed and vertical path are controlled by 
either pitch or thrust in different autoflight modes, the disparity in organization between the mode 
annunciators and the mode control panel doesn’t reinforce the conceptual distinctions that reduce the 
apparent complexity of possible mode combinations. On the HSCT, an important design issue is 
whether the potential synthetic vision displays should be conformal with the outside world as seen 
through the side windows. If a visual model inconsistent with reality is formed by viewing a synthetic- 
scene, and this inconsistency interferes with transitioning to using real world information, then the 
design should attempt to make the synthetic scene information conform with the real world 
informaUon. 


Fundamental human limitations (e.g., memory, computation, attention, decision-making 
biases, task timesharing) should not be exceeded. 


Even though abilities vary between individuals, humans in general have fundamental 
charactensues that limit their task performance. For example, limitations exist on the amount and 
endurance ot information kept in short-term memory, and on the ability to perform explicit complex 
computauons, to make decisions involving many interacting variables, and to complete several separate 
tasks simultaneously. However, tasks requiring any amount of these activities should not be 
summarily allocated to automation (Fitts, 1951); rather, it is important for the designer to recognize 
inherent limitations and to make sure that they are not exceeded. Design of systems which are simple 
to understand and use is a fundamental method of assuring human limitations are not exceeded. For 
example, an enormous amount of information will be available electronically onboard the HSCT, yet 
the night deck design clearly should not display all this information all the time because of human 
limitauons in percepuon and informaUon processing. Another example is that humans have limitadons 
in perceptual judgment which may make it unreasonable to expect the flight crew to be able to judge the 
posiuon of landing gear of die HSCT on airport surfaces without some perceptual aid. Although flight 
crews can manage this task on conventional aircraft, the unique geometry of the HSCT places the crew 
much further, physically, from the landing gear. 
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PI-9. Fundamental human capabilities (e.g., problem solving, inductive reasoning) should be 
used to advantage. 

Just as humans have inherent limitations, they also have inherent strengths. These include 
such capabilities as problem solving in novel situations, inductive reasoning, and error recovery. It is 
not the case that tasks should be designed to require the use of such abilities; rather, it is important for 
the designer to recognize that these strengths exist and that they may be used when necessary. 

P I - 1 0 . Interference among functions or tasks which an operator may perform concurrently should 

be minimized. 

The procedural flow of tasks and the layout of equipment in the flight deck must be designed 
so that conflicts do not arise when a human operator is performing more than one task concurrently. 
At a physical level, flight deck controls such as thrust levers should be placed such that when a flight 
crew member is using those controls his or her arm does not visually block any other display or 
control that may be in use. And at a procedural level, task sequences that may likely or even possibly 
be completed in the same time period should not call for conflicting actions (e.g., one procedure calls 
for activating a subsystem, while the next procedure calls for deactivating the same subsystem). 


4.4.4 Pilots as Flight Deck Occupants 

PO - 1 . The needs of the flight crew as humans in a potentially hazardous work environment 
should be supported. 

Humans have basic physiological limitations, and the aircraft flight deck should protect them 
from the hazards of the external environment. Examples include oxygen and pressurization, radiation 
exposure levels, the effects of oscillation and vibration, and ingress and egress from the seating 
provided. Particular concerns for the HSCT are protection from explosive decompression due to the 
high cruise altitudes, and protection from head strikes due to the small cockpit size. 

PO - 2. The design should accommodate what is known about basic human physical 

characteristics. 

Humans vary in physical characteristics, such as, reach, height, strength, etc. The flight deck 
design should accommodate the variation among humans with respect to these characteristics, and the 
databases for determining norms, variances and ranges should reflect the anticipated worldwide 
population of human operators. For example, flight deck seating and control placement should not be 
designed merely to accommodate people from 5’ 2” to 6 ’3” in height; rather, it should accommodate the 
differences in upper and lower leg lengths, torso length, upper and lower arm lengths, and hand size 
and grip strength that exist between a 5th percentile Oriental female and a 95th percentile African male. 
Of particular interest for the HSCT are potentially different pilot vision and arm reach/manipulation 
requirements related to the higher than normal levels of oscillation and vibration anticipated during taxi 
operations. 

PO- 3. Peripheral activities which are indirectly related to the mission objectives should be 
supported. 

The flight crew engages in peripheral activities that may affect the safety, efficiency, or comfort 
of the flight. Examples include preparation of passenger manifests, completing company paperwork, 
and making public address announcements to the cabin crew and passengers. These should be 
identified and functionally supported by the flight deck design, because paperwork or other items may 
obscure an important display if they cannot be placed in a suitably designed location. Right crew 
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members also will be eating, drinking, and visiting the cabin during the flight, so the flight deck design 
must accommodate food and drink containers and provide for easy seat ingress and egress during 
flight operations. Any of these activities can interfere with pilot performance if not properly 
accommodated by design. 

PO-4. The design should account for major cultural norms. 

An HSCT aircraft will be used by both multi-national and multi-cultural airlines. Conceptual 
models of system function and methods for task performance, such as the inherent meaning of colors 
and accepted norms relating switch positions to system status (e.g., in Britain it is common for room 
lighting to activate when the associated switch is flipped down), often vary across cultures. These 
cultural norms should be recognized and accommodated to the extent possible, and any violations must 
be identified as potential problem areas for training flight crew members from those cultural 
backgrounds. 


4*5 — Framework for Design Guidelines 

This section is provided as a bridge between the principles presented above and the functional 
requirements, system requirements, flight deck requirements, initial design concepts, and final 
integrated design as presented in the flight deck design process diagram in Figure 1. The current 
content of this section is also intended to serve as an introduction to the planned collection and 
development of the complete set of guidelines, which will be included in Part 2 of this document. 

Because principles are general statements about functional design concepts that are theoretically 
driven and in researcher's language, they cannot necessarily be interpreted directly by the design 
engineer. The principles provide the rationale for requirements and design concepts, but they must be 
translated into more specific statements in language more appropriate for the design community. 
Guidelines, which are low level statements intended to provide detailed guidance in making design 
decisions, are an effective way to make this translation. Guidelines are more general than 
requirements, and thus adherence to them is often relative and subjective rather than absolute and 
objective. Categories of guidelines are provided below to help the system developer allocate functions 
and create initial design concepts that satisfy the principles and, thereby, embody the underlying flight 
deck design philosophy. b 6 


Tables 2 and 3 show the categories of guidelines contained in this section. In Table 2, crew 
issues are listed along the rows and flight deck features along the columns. Crew issues represent 
general classes^of crew centered constraints, and correspond to the following crew roles described 
earlier: Crew Coordination is an issue relating to pilots as team members; Authority relates to pilots as 
commanders; Workload , Situation Awareness, and Errors relate to pilots as individual operators; and 
Safety and Comfort relate to pilots as Occupants. Flight deck features correspond roughly to a 
taxonomy identified through a scaling analysis of researchers' and engineers' sorting of preliminary 
guidelines. Displays, Controls, Automation, and Alerting. In Table 3, these flight deck features are 
combined to produce guideline categories specific to issues relating to these combinations. 

_ Guideline categories are generated for all combinations of crew issues and flight deck features 
(Table 2), and all combinations of flight deck features (Table 3). This ensures that all pilot roles and 
the issues that are relevant to them are addressed in all of the relevant design features of the flight deck, 
and that all issues relating to how flight deck features interact are also represented. The guidelines 
related to flight crew issue by flight deck feature combinations are organized by flight deck features 
since this should be more consistent with the way designers think about these issues. Guidelines are 
stated in terms of the categories listed in the cells of the tables, and these categories arc underlined in 
the text to allow easier cross-reference to the tables. 
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Table 2. Guideline categories relating to combinations of crew issues and flight deck features. 


Crew Issues 

Flight Deck 
Features 

Displays 

Controls 

Automation 

Alerting 

Crew 

Coordination 

(pilots as 
team members) 

cross checking 
interference 

cross checking 
interference 
equal access 

clear 

responsibilities 
system state 

retention 
equal access 

Authority 

(pilots as 
commanders) 

information access 

limits 

automation levels 

error checking 

Workload 

(pilots as ind. 
operators) 

placement 

visibility 

response time 

task mapping 

integration 

comparisons 

mental 

transformations 

importance 

clutter 

access levels 

placement 
visibility 
response time 
procedure mapping 
effort 

transcribing 
tactile cues 

monitoring 

intervention 

complexity 

normal/non-normal 

importance 

inhibits 

content 

integration 

Situation 
Awareness 
(pilots as ind. 
operators) 

system feedback 
orientation 
units 
labeling 

process feedback 

automation feedback 
prediction 
complexity 
involvement 
mode transitions 

enabled status 

Errors 

(pilots as ind. 
operators) 

modes 

mental models 
actuation feedback 
prevention 
detection 

symbol confusion 
orientation cues 
placement 
stable reference 

modes 

mental models 

actuation feedback 

protections 

consistency 

distinction 

recovery 

inodes 

mental models 
states 

confusability 

Safety 

(pilots as 
occupants) 

fatigue 

food/drink 

fatigue 

food/Jrink 

inadvertent actuation 
head strike 

masking 

volume 

Comfort (pilots 
as occupants) 

fatigue 

environmental 

transients 

volume 

onset 


To apply these guideline categories, it is recommended that the system designer consider the 
relevance of each guideline category to specific design problems. The categories arc explained in detail 
below, and sample guidelines are provided for each one. Where possible, references to existing 
human interface guidelines and standards are provided for further reference. This is intended to help 
the designer set quantities for specific requirements based on the attributes of the system under 
consideration, and to trace the justification for specific requirements to the appropriate literature. 
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guideline categories and the high level guidelines provided comprise an initial attempt to 
describe the crew-centered design philosophy at a more specific level than provided by the principles. 
While they are intended to be fairly comprehensive, the process of collecting and/or developing lower 
level guidelines for Part 2 of this document may require modifications/additions to the material 
provided here. 


4.5.1 Crew Issue/Flight Deck Feature Guidelines 

Displays 

Displays/Crew Coordination: For cross-checking, displays should be designed to allow both pilots to 
monitor the activities of the other pilot, including data entry, mode selection, system management, and 
control tasks. To reduce interference, displays should be designed to prevent the activities of one 
crewmember from conflicting with those of another. 

Displays/Authority: Information access should be allowed to any on-board information that could be 
used by the flight crew in their decision making, because the full range of decision requirements cannot 
be anticipated by the designers. 

Displays/Workload: The placement of displays should minimize the amount of visual displacement 
required to monitor multiple visual information sources. For example, the information required to 
perform common combinations of tasks should be co-located or integrated. Displays that rely upon the 
relationship of the pilot's body with the axes of the aircraft should be located appropriately; for 
example, the primary flight display should be located along the central forward axis of the pilot To 
ensure Vi s ibil i ty , displays should be easy to read from normal pilot viewing angles and under the range 
of vibration and forces due to ma^ avers, and pilots should not be required to alter their position or 
posture to read a display. Display response times should provide positive feedback of all flight crew 
inputs quickly enough that the pilot does not attempt to repeat the input, thinking that the fust attempt 
was unsuccessful, and quickly enough to prevent the pilot from having to perform tasks more slowly 
than the natural pace or the pace required by other factors. If the system cannot provide the final result 
of a commanded process within the required time, it should still indicate to the pilot that it is processing 
the command. Displayed responses to flight control inputs should be rapid enough to prevent pilot 
induced oscUlations. To support appropriate task mapping , displays should be located and formatted 
to directly support the pilot's procedural task sequences. When a task or a common combination of 
tasks requires the use of multiple pieces of information, these different pieces of information should be 
i nte g rated into a common display area. Such display integration is especiaUy important when the crew 
needs to make comparisons between multiple pieces of information. The need for the flight crew to 
perform mental transformations of information, such as mental rotations, interpolations 
extrapolations, or other calculations, should be minimized by presenting the information in the form 
that is most immediately useful for the task or tasks at hand. In cases in which information 
presentation order is not dictated by task sequences or natural relationships between the pieces of 
information, the information should be ordered on the basis of importance , which should also be 
indicated by visual coding methods. To prevent clutter , displays should not contain so much 
information that the pilot cannot immediately find whatever information is needed. Issues include 
finding information again after the pilot has to look away to perform another task, and accidentally 

one piece of information for another because they are too close together or are insufficiently 
differentiated. The number of steps or access levels required to get information should be minimized. 

I nose pieces of information that are needed frequently or needed to support critical tasks should be 
accessible with the fewest steps. 

Displays/Situatio. rareness: To ensure appropriate system feedback , the flight crew should always 
have access to informauon about what the various on-board systems are doing and that access should 
be appropriate to the current pilot responsibilities. For example, during cruise flight, the crew should 
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be able to monitor flight control behaviors to verify that balance and thrust are symmetrical and that the 
autopilot is not correcting for any undetected problems. The orientation of displays that depict an 
object with reference to another object should be consistent with that relationship. For example, 
displays of the immediate external environment should be oriented consistent with the relation of the 
aircraft's major axes to the environment. Units of measure should be provided for displays of values, 
particularly where multiple units may be possible, as in altitudes (feet vs. meters), altimeter settings 
(inches of mercury vs. millibars), and fuel quantities (pounds vs. kilograms). Multi- function display 
pages or windows should contain titles and labeling to indicate the page or window contents. The 
crew should not have to scan the contents themselves to determine the function of the particular page or 
window. 

Displays/Errors : There are several types of mode errors associated with displays. In one, the display 
operates in different modes itself and depicts information differently in the different modes. In 
another, the display indicates the mode of some other device or system, such as the current autoflight 
control mode. In all cases, the display should clearly and unambiguously indicate the current mode. 
For critical functions such as flight control, where mode confusions can cause accidents, the mode 
indications should be given redundantly in several locations and with several types of cues. For 
example, the designer should consider altering major elements of the primary flight display in different 
flight control modes. The organization of display functions should support simple and accurate mental 
models* to aid the pilot in figuring out how to access required information. Positive actuation feedback 
shoulr Se displayed for all control inputs. To the fullest extent possible, displays should be designed 
to prevent errors by supporting the natural sequences of actions required to perform tasks, providing 
the information required with a minimum of display management, and ensuring that the information is 
unambiguous and evident Displays should also be designed to make the current state of the aircraft 
and all its systems unambiguous and evident to permit detection of errors immediately after they are 
made. Symbol confusion should be reduced by designing symbology to be so distinct and 
distinguishable that it prevents any possible confusion between different symbols and indicators. For 
spatially mapped displays, unambiguous orientation cues should be provided to prevent map reversals. 
The designer may consider altering the whole appearance of the navigation display, for example, 
depending on the display mode (heading/track-up or north-up). Generally, display placement should 
prevent parallax, particularly when display locations must be matched to control devices such as bezel 
button locations. In some cases, however, such as displays with a touch-screen overlay, parallax may 
be used to advantage. Stable reference display elements should be provided on changing graphic 
displays. For example, altitude indicators should depict altitude in reference to a stable point or scale. 

Displays/Safety. Display design, placement, and visual characteristics (e.g., brightness, contrast) 
should reduce pilot eye fatigue. Displays should be protected from food or drink spills, and should 
not fail if such spills occur. 

Displays/Comforr. Display design, placement, and visual characteristics should not cause pilot eye 
fatigue . 


Controls 

Controls/Crew Coordination : For cross-checking , controls should be designed to allow each pilot to 
determine what control inputs are currently being made by the other pilot. To reduce interference , 
controls should be designed to prevent the activities of one crewmember from conflicting with those of 
another while performing different tasks. To ensure equal access , control devices that may need to be 
operated by cither crewmember as pilot flying or pilot not flying or during abnormal events, should be 
accessible by both pilots. Control devices critical to safe flight should be placed so that either pilot can 
operate the devices without disrupting their other tasks when operating the aircraft alone. 
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Controls/Authority. With respect to control limits, pilots should be able to command the fuU ranee of 
system performance or capability. If protection limits are provided, the control devices should only 
prevent the crew from unintentionally violating limits but allow the crew to do so intentionally without 

crew^s htputs 6r P rotect ‘ on s y st ®ms should not be designed so they can override the flight 
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Controls/Workload-. Control placement should minimize pilot physical resource conflicts. For 
example, it should prevent the pilot from having to make simultaneous or nearly simultaneous control 
inputs m widely separated locations. Also, those controls that relate to the position or orientation of a 
device (or the aircraft itself) should be located consistently with that position or orientation. For 
example, flight control device movement should be consistent with the movement axes of the aircraft. 
Control funcuons should have good vi sibility and be readily apparent. If a device is used for multiple 
functions, all the available functions should be indicated; however, the use of a single control device to 
Pf 1 f multiple functions is discouraged due to the increased risk of mode errors. The response time 
of feedback to control inputs should be rapid enough to prevent multiple input attempts or pilot induced 
oscillations. For procedure mapping , if control device placement is not dictated by such concerns as 
immediate access, popular use, or relation to pilot body position and orientation, placement should be 
consistent with the order of pilot procedures. The amount of effort required to operate a device should 
be such that inadvertent actuation is unlikely, use of the device does not cause fatigue, and the pilot can 
override built in protections. For example, the input force required to counteract the automatic “stick 
pusher operation should not be greater than that possessed by the weakest pilot of the projected user 
population. To reduce the workload associated with transcribing , the flight crew should not be 
required to enter the same information into any one system multiple times, or to enter the same 
information into multiple systems. Once the crew has entered the information into one system, it 
should be transferable to other systems. To make use of tactile cues, the flight crew should be able to 
find and idenuty control devices by touch, and determine by touch whether previous actions have 
actuated the devices. 


Controls/Situation Awareness: To ensure that the flight crew has adequate process fredharlr control 
devices should reflect the states of the processes they are controlling. This allows the crew to 
determine process state from observing or monitoring the behavior of the control device, and it 

facilitates graceful transfer of control because the crew can assume control with the device in the proper 
position. K ^ 


Controls/Errors: There are several types of mode errors associated with controls. In one, the device is 
in the wrong mode for the input being attempted. An example is the wrong control display unit (CDL) 
page being displayed tor the operation desired. In this case, an input can have unintended effects. The 
system should be designed to prevent this type of error by providing unambiguous indications of 
system state, and to allow easy recovery from this type of error by ensuring that inputs can be canceled 
or reversed. In another, a single device may be used to select multiple system modes, such as a single 
knob or push-button used to select multiple flight control modes. In this case, the system should be 
designed to prevent the selection of an undesired mode. Methods to accomplish this include requiring 
very different actions to select the different modes and clearly indicating the selected mode at all times. 

I ne operauon of control devices should be consistent with the simple and accurate mental models the 
flight crew develop in training ot the process being controlled. For example, a mimic diagram of a 
process control system (such as the hydraulic system) might provide control points for valves and 
actuators. Positive actuation feedback that a device has been activated should be provided For 
functions critical to sale flight, such as autopilot status, these indications should be salient enough that 
pi ots cannot miss them. Protect i ons should be provided for potentially destructive actions, such as 
deleu ng a flight plan. For steps that can delete data, a confirmation step should be required and the 
acuon should be reversible. All types of protections should allow pilot override with unambiguously 
intentional acuon. Consistency should exist between actions with similar goals. For example, if the 
same option appears on multiple display pages, it should always appear in the same location on all 
pages with the same label, and it should work the same way. As another example, one type of pilot 
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action should always be used to de-select the current flight control mode so the pilot does not have to 
determine the current mode and remember what specific action is required to de-select it. Similarly, 
distinction should exist between actions with dissimilar goals. For example, the actions required to 
select different types of autoflight modes should be different. For error recovery , the systems should 
be designed to allow the pilot to easily correct any errors, assuming that the guideline above for rapid 
detection of errors is followed and errors are detected quickly. 

Controls/Safety. Control design, placement, and force requirements should not cause pilot fatigue. 
Controls should be protected from food or drink spills, and should not fail if such spills occur. 
Control devices should be designed to prevent inadvertent actuation due to ancillary pilot activities, 
such as seat ingress or egress or using food trays, cups, documentation, or other objects. Control 
devices should be designed to prevent inadvertent actuation from pilot head strikes , and to prevent 
such head strikes from injuring the pilot. 

Controls/Comfort: The crew should be able to adjust environmental parameters to maintain a 
comfortable working environment. 


Automation 

Automation/Crew Coordination: To ensure clear responsibilities , it should be conspicuous what 
activities each crewmember and the automation are currently responsible for. The crew must be able to 
determine immediately whether a function is under automatic, semi-automatic, or manual control, and 
if a function reverts from automatic to manual control, that reversion must be annunciated 
unambiguously to the crew to ensure they are aware of the reversion. The current system state of each 
subsystem should also be clearly indicated, so that if control is transferred from automation to the pilot 
he or she can take control of the process without disruption. 

Automation/Authority: Pilots should be able to select or command any automation level that the flight 
deck systems can provide. If the automation is unable to perform at the selected level, it should inform 
the pilot that it cannot do so and why, and operate at the highest level available. 

Automation/Workload: To reduce workload associated with monitoring , automation should not be 
designed so the pilot is required to continually watch it over long periods of time. The flight crew also 
should be able to intervene directly, and at any time, in automated processes. This means that there 
should be feedback about what the automation is doing, and the crew should be able to reassume 
control from the automation without unduly disrupting the process being controlled. The complexity 
of a system should be balanced with the need to retain simplicity so the pilot can readily understand 
how the automation functions, what the automation is doing, and how to make the system performed 
desired functions. This is necessary because an overabundance of system capabilities, functions, and 
modes can cause pilots to make errors, and many pilots do not use advanced features of systems such 
as the Flight Management System because the benefits do not seem to outweigh the additional training 
and workload required to use them. 

Automation /Situation Awareness: The crew should always have access to automation feedback so 
they can intervene, if needed, in the process the automated systems are controlling. There should be a 
clear indication of what automated systems are currently programmed to do so the crew can predict 
automation behaviors accurately. For example, a pilot should be able to determine quickly whether the 
aircraft will capture an altitude in its current flight control mode. To reduce complexity , automation 
should be designed to support simple but accurate conceptualizations of how it operates so pilots can 
easily determine what it is doing and what it is going to do. Automation should be designed so pilots 
can retain an appropriate level of involvement in the process in order to maintain situation awareness 
and skill levels. When automated systems begin a mode transition , that mode change should be 
annunciated to the crew in a salient way to ensure that the crew is aware of it. This is particularly 
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important for mode changes that were the result of earlier flight crew programming or were not 
commanded by the crew at all (such as mode reversions due to loss of a guidance signal). 

Automation/Errors: The current automation modes should be readily apparent to both pilots. It should 
not be possible to confuse modes, either by selection or by symbology of mode annunciations. 
Automation should support simple and accurate mental models of its operation so the flight crew can 
easily determine what automation is doing and anticipate what it is going to do. Feedback about the 
current states of the automated systems and the process they are controlling should always be 
provided. 

Automation/Safety. To prevent masking , automation behavior should not be made so smooth that the 
pilot loses information about what the automation is doing. Any information that is masked 
kinesthetically should be replaced by other means such as with visual displays, though the ability of 
the pilot to directly sense automation control actions is often preferable. 

Automation/Comfort : Automation actions should not produce disruptive transients . For example, 
transitions between modes or transfer of control between crew and automation should not cause 
sudden changes in system state, except when the crew forces such a sudden change intentionally. 


Alerting 

Alerting/Crew Coordination: Alerting systems should provide retention , with all alert messages 
retained in a log so the crew can review them later. This is particularly important if one pilot can cancel 
or clear an alert message before the other pilot has a chance to review it To ensure equal access to 
alerts, they should be given in a way that presents them equally to both crew members. 

Alerting/Authority: To the extent that the flight deck systems can provide error checking of crew 
inputs, the system should alert the crew of the condition or situation but should not override the crew if 
they persist. 

Alerting/Workload: Status indications should permit the flight crew to quickly and easily distinguish 
between normal and non-normal situations. For example, the designer may specify that many status 
indicators remain quiet and dark during normal operations to avoid dewing the crew's attention 
unnecessarily. Alerts should be distinguishable based on importance and the immediacy of response 
required. Alerts that do not need to be recognized by the crew immediately during highly critical flight 
phases, such as takeoff and landing, should be inhibited until the crew can attend to them without 
disrupting critical tasks. Critical alerts should provide useful content along with the alert itself (such as 
the voice annunciations of the Ground Proximity Warning System - GPWS). When possible, alerts 
that are associated in a meaningful way should be integrated . 

Alerting/Situation Awareness: The enabled status of alerting systems (i.e., whether the systems are 
active) should be indicated to the crew. The crew should not be able to unknowingly operate the 
aircraft with an alerting system disabled. For example, if the Ground Proximity Warning System has 
been disabled by pulling a circuit breaker, this fact should be clearly communicated to the flight crew. 

Alerting/Errors: To reduce the chance of confusabilitv . alerts should be clearly distinct. 

Alerting/Safety: Aural alert volume should be loud and clear enough that the crew cannot miss the 
alerts, but not so loud as to disrupt other pilot responsibilities such as radio communications. 

Alerting/Comfor *■ Aural alert volume should be loud enough that the crew cannot miss the alerts, but 
not so loud tha‘ • . causes discomfort. The onset of alerts should not be so sudden that it unnecessarily 
startles the crew. 
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Table 3. Guideline categories relating to combinations of flight deck features. 


>1 


Flight Deck 
Features 

Displays 

Controls 

Automation 

Alerting 

Displays 

symbol consistency 
format consistency 
layout consistency 
coding consistency 
distinction 




Controls 

direction consistency 

proportional 

movement 

contiguity 

feedback 

symbol consistency 
layout consistency 

motion consistency 
distinction 



Automation 

commanded/actual 
display management 

feedback 

override 

pilot 

review/confirmation 

interactions 


Alerting 

content 
salience 
highlighting 
consistency 
display access 

acknowledgment 

review 

authority limits 
faults 

consistency 

conflicts 

contradictions 

combinations 

distinction 


4.5.2 Flight Deck Feature/Flight Deck Feature Guidelines * 

f 

» 

Displays/Displays-. For symbol consistency , different displays should not use different symbols to I 

represent the same thing. For format consistency , similar functions of different displays should have a f 

common format For example, latitude/longitude coordinates should be represented in the same way 
across all devices and information sources (including paperwork) that use or display them. For layout 
consistency , similar functions should appear in similar locations on all displays that use them. For | 

example, if an Enter function is provided on multiple displays, pages, or windows, it should appear in ! 

the same place every time. To maintain coding consistency , different displays should use the same f 

visual coding techniques to represent the same intention. For example, color, size, and highlighting 
should have consistent meanings across all displays and information sources, including paperwork. 

For distinction , different functions should have readily apparent differences in appearance to prevent 
the crew from selecting a different function than intended. 

Displays/Controls: To maintain direction consistency , control devices that affect the movement of an f 

object on a display should cause movement of the object that is consistent with the direction of control ' 

movement. Control devices that affect the movement of an object on a display should use proportional 

movement to ensure that movement of the object is consistent with the magnitude of control 

movement. For contiguity , display indications related to control actions should if possible be placed 

close to the control device. For example, if keyboard input causes text to appear on a display far 

removed from the keyboard, a secondary display should be provided next to the keyboard so the pilot 

does not have to look far away from the keyboard to check die input. Positive feedback should be 

given for the operation of every control device. Tactile feedback should be provided to indicate that the 

control has been actuated, and positive feedback of system acknowledgment should be provided to 

prevent the pilot from attempting multiple inputs due to lack of response. For example, if the pilot 

attempts to select a flight control mode and the system is not properly configured for that mode, an 

indicator to this effect should be provided; having the system simply not assume the selected mode 
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may imply that the control actuation was not received by the system, and the pilot may attempt multiple 
inputs. 

Displays/ Automation: To help the crew effectively monitor automation control actions, indications of 
commanded and actual values should be provided for functions under automated control. If 
automation is authorized to perform display management , such as switching display pages or windows 
under certain conditions, such management should not disrupt ongoing pilot activities. 

Displays/Alerting: For alerts that require an immediate response, the content of the message should be 
contained in the alert itself; the pilot should not have to refer to multiple display sources before taking 
action. Critical alerts should be presented aurally, since sounds don’t require directed attention. The 
salience of alerts presented on visual displays should be sufficient to draw the crew's attention to the 
display. However, flashing messages, for example, are not recommended because they can be hard to 
read; instead, any flashing should be applied to the background or to display elements such as 
highlighting that the crew does not have to read. In keeping with the previous guideline, important or 
new information associated with an alert should be displayed using highlighting techniques so the crew 
does not have to search a display to find the information needed. For consistency, an alerting 
philosophy should be applied to the overall flight deck so the crew does not have to remember what 
type of action is required to access a specific alert message. Also, when information associated with 
an alert is contained on a display page or window that is not currently shown and the alerting system 
has the authority to automatically display that page or window, the designers should take care that such 
display reconfiguration does not restrict flight crew display access or disrupt ongoing crew activities. 

Controls/Controls: To maintain symbol consistency , different control devices should not use different 
symbols for the same thing. For layout consistency , different control devices that support the same 
functions should have the same layouts. For example, all keyboards should have the same key layout. 
For motion consistency , control devices that are intended to behave the same way should employ 
consistent motions. For example, if a clockwise rotation is used to increase a particular system value, 
then all rotary control devices of the same type should work the same way. To maintain distinction 
different control devices that are intended to behave differently should appear and feel dissimilar. 

Controls/Automation: Control devices should provide feedback as to the effects of automation on the 
states of the processes they are controlling. This allows the pilot to determine process state from 
observing or monitoring the behavior of the control device, and it facilitates graceful transfer of control 
because the pilot can assume control with the device in the proper position. To allov r for overrides , an 
unambiguous means should be provided for the crew to take manual control of an automated process. 
To allow for pilot review and confirmation , lengthy commands constructed by the crew should not be 
sent to the automation for execution until the crew has had the opportunity to check die commands for 
accuracy. 

Controls/Alerting: The crew should be able to acknowledg e alerts without erasing or deleting the 
information contained in the alert. The crew also shoulJ oe able to review the contents of previous 
alerts by accessing them from a message log. 

Automation/Automation : Automation features should not have complex or subtle interactions that 
prevent the crew from effectively monitoring automated actions or intervening in automated processes. 
Automation features should also not interact in ways that create seemingly unpredictable system 
behavior. 

Automation/Alerting: When an automated function nears its control authority limits , the crew should 
be alerted in time to intervene effectively. The crew should be alerted whenever automation encounters 
fcull& that call into question its ability to perform at the required level of reliability and accuracy. 
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Alerting/Alerting: For consistency , alerts with similar intentions should have similar presentations. To 
reduce conflicts lor crew attention, multiple alerts should not be given simultaneously unless they are 
clearly prioritized. Alerting systems also should be integrated to avoid contradictions in information 
given to the crew. For example, it should not be possible for one on-board system to tell the crew to 
climb and another to tell the crew to descend. Multiple alerts should be integrated into a single higher 
level combination alert when doing so would give the crew the most direct insight into the nature of the 
underlying problem. For distinction, ditferent alerts with different intentions should sound and appear 
dissimilar. 


M Conflict Resolution 

Those involved in the flight deck design process know that design decisions involve 
compromise. Economic, regulatory, safety, and operational constraints continually conflict. In the 
sense that human-centered design principles and guidelines are flight crew constraints that help shape 
functional, flight deck design and integration, and systems requirements, they may conflict with other 
constraints, such as market, regulatory, physical, etc. More important, at least within the scope of this 
document, is the fact that these principles and guidelines will sometimes create conflicts among 
themselves in the process of developing design concepts and making design decisions. It is the belief 
of the authors that guidance on identifying and resolving these conflicts may be one of the most useful 
services this document can provide. 

We believe that there may be a general priority order assigned to classes of principles and 
individual principles. For example, those that involve the pilot as team member may generally be 
higher priority than those that involve the pilot as commander, which may generally be more important 
than those that involve the pilot as an individual operator and so forth. There may be generally 
applicable fixed priorities among individual principles as well. For example, principle PI-1 states that 
the pilot should be appropriately involved in all critical flight functions and tasks for which he or she is 
responsible. Yet in certain conditions, this involvement may exceed attentional and information 
processing capacity of the pilot (a violation of PI- 10, i.e., fundamental human limitations should not 
be exceeded), leading to high workload and pilot errors. Hence, one might argue that PI- 10 has a 
higher fixed priority than PI- 1 . 

But in the final analysis, which principle or guideline takes precedence over another in regard 
to developing a specific design concept or making a specific design decision, is usually context- and 
issue-specific. Therefore, methods and metrics are needed to identify and resolve conflicts among 
principles and guidelines. Often, resolution among competing principles or guidelines is left to the 
individual developing the design concept or making the design decision. A multi-disciplinary team 
using consensus management techniques to maintain consistency of design concepts and design 
decisions with various guidelines and to resolve conflicts is often used, and is recommended here as a 
more reliable and consistent method by which to make such trade-offs. We advocate, where possible, 
that some objective criteria be used to resolve conflicts. This may be the same set of criteria that is 
used to validate requirements or evaluate initial concepts. Test and evaluation will ultimately determine 
if the trade-offs that were made during the design process were appropriate. It is important to note that 
conflict resolution should be guided by the performance objectives shown in Figure 3; that is, the 
effects of the trade-offs among principles and guidelines on overall flight crew/flight deck 
performance, flight crew performance, and individual pilot performance, in that order, should be 
assessed. Where major differences of opinion or controversy surround conflicts among principles or 
guidelines, trade studies to evaluate different design solutions derived from different weighting of the 
importance of competing principles or guidelines might be appropriate. Part 2 of this document will 
address the issue of conflict resolution in greater detail. 


5.0 CONCLUDING REMARKS 


A crew-centered flight deck design philosophy has been described which seeks to elevate 
human performance and system operability design issues to the same level of importance as the past 
focus on technological issues, such as hardware performance and reliability, and to give them the same 
prominence as other major aircraft design areas such as aerodynamics and structural engineering. A 
conventional design process is first outlined, and points in this process at which it is appropriate to 
apply the crew-centered design philosophy are identified. 

The philosophy itself is expressed as a set of design philosophy statements, guiding principles, 
and high-level design guidelines focused on issues related to the respective roles of the flight crew and 
the flight deck automation. The philosophy casts the pilots in the roles of commander, team member, 
individual operator, and occupant, which helps to identify major categories of design issues important 
to a crew-centered approach. The philosophy casts the flight deck automation in the role of a tool 
whose single purpose, regardless of the level of sophistication and complexity, is to aid the pilot in 
accomplishing the mission. Note that the philosophy explicidy assumes that the flight crew will 
remain an integral component of safe and efficient commercial flight for the foreseeable future. The 
basis for this assumption is that human skills, knowledge, and flexibility are required in the operation 
of complex human/machine systems in the unpredictable and dynamic air transportation system 
environment. The philosophy also suggests that the success of the overall flight crew/flight deck 
system depends on the designer understanding the total system, including its human and automated 
components and the way these components interact to accomplish the mission. 

Two matrix structures are presented to organize the large number of design guidelines that exist 
in the literature and to aid the process of identifying design areas/issues for which design guidelines are 
lacking. These matrices account for both the roles of the flight crew and for different categories of 
flight deck features (i.e., displays, controls, automation, and alerts). High-level guidelines were 
provided for each cell of both matrix structures, primarily to serve as descriptors of the classes of 
specific guidelines that will eventually be identified relevant to each cell. 

Whenever design decisions are made, they involve trade-offs among benefits and risks 
associated with different design solutions. In terms of the philosophy, trade-offs will be required 
between human-centered priorities and other priorities such as costs, weight, and hardware reliability. 
Further, there will be trade-oils between competing principles and guidelines within the philosophy. 
General guidance and methods for resolving such conflicts are presented as an important part of the 
overall approach, although further work is planned to provide more specific assistance. Finally, it is 
argued that adhering to a human-centered design philosophy is necessary but not sufficient to assure a 
good design. To improve total system performance, early and continuous test and evaluation of design 
concepts, using pilots representative of the actual airline flight crews who will routinely fly the aircraft, 
is a necess ary complement to a solid "up-front" set of design principles and guidelines. Proposed test 
and evaluation methods, experimental measures, scenario development guidance, etc., are described in 
Appendix A. 

Many engineers and designers would claim that they already perform human-centered design. 

It is important to note, however, that we do not define human-centered design as simply applying 
"human factors” to the design process. Rather, we believe that an explicit design philosophy must be 
clearly described and applied systematically within the framework of a well- defined design process. 
This document is intended to be a first step in this approach. 
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APPENDIX A: TEST AND EVALUATION 


Objectives 

ooo-i P °H° r deSI j ns ^ cosd Y to correct on ce installed in an operational environment While changes 
InESo d f ^jed crew interlaces can be expensive, changes to systems because of poor function 8 
allocation, levels of automr ion, or other functional design decisions, can be even more extensive 
Understanding crew-dnveri requirements, and what constitutes good design practice in terms of crew- 
centered design principles and guidelines, can help assure that preliminary designs go™ But 
any design solutions may generally adhere to the design philosophy and yet have major differences 
m degree ol operability. Trade-offs must be made in complying viith different princTples^d 
guidelines, and the principles and guidelines can be interpreted in different ways and applied 

Sno" ndm f ° nlhe COntext - F ! ence ’ a second of a crew-centered design approach is 

making usability evaluauons an integral part of design. Usability refers to how easy a design or a 

system is to use (operauon can be learned and remembered easily, the system can be used efficiently 
and with minimum error, am 1 users are satisfied with it). Pilot-in-the-loop evaluations assess usability 
and total system performance, that is, whether the overall man-machine system accomplishes the 
^ )e ^ 0n ^ anCe ob,ectlve f This section provides test and evaluation guidance and recommendations 

throu^hom 1 !^ ‘h™* ° f Prices, measures, tools and methods ’ ^ scenarios that can be applied 
n i o^r! 10 u l ^ lL . desi 8 n i process. Test and evaluaUon is an important complement to a crew-centered 

material ^ deSed here S ° Phy ' ^ 2 ° f ^ document Kt wiU elaborate in more detail on much of the 


Practices 

C11 _ ™ ere , arc s f v ^ al important test and evaluation (T&E) practices to be foUowed to achieve 
successful and cost-effective design. Each will be briefly described below. 

( 1 ) The most important T&E practice is to evaluate early. As soon as preliminary design 
concepts are defined m accordance with the set of funcdon, design and integration, andTystems 

a va ? ety 0t h S ? bll, i! y tCStme methods can ** applied- The earlier concepts are tested, 
y r" d “j? Wh ° e ’ the cas,er and more cost-effective it is to make changes. Early testing 
also can help refine and improve requirements and determine if the trade-offs made among guidelines 
were appropnale Tcsung flight deck design concepts as a whole earlier in design isTSuK 

overall £™A^cTve’ y ° P “ mi2ed " deSig " S " <X °P ,,mal frora 

(2) The design process depicted in Figure 1 shows that test and evaluation, as with any design 
activity, ,s necessarily iterative and serves as a feedback loop (design-evaluation-reSn) TseSh 

“r m . ,tial conc °Pt’ new evaluauons must be performed to determine if (a) the 

design change had the desired positive effect and, (b) no new negative effects or interactions with other 

hnihX^^T 5 ’ °[ l u Sks w c f e ^inadvertently introduced. Formal and informal evaluations should 
b d ^ d ’ a !? thc £ oal °J P J rovld,n g diagnostic information for redesign. All evaluation 

Sfteram srag« <SSg S nc“d'c *" Pr0CeSS - al,h0UEh S ° nK maybe more >° 

on .k n 3 k?T W c CCnt i Cre f d cs |gn focuses on pilots and their interaction with the flight deck rather than 

u^rs ihS k ^ lC k hn( ! l0 f ' LsC r f Usab,l 'ty lcslin S for n ‘8 ht deck systems should be done with 
oiSrra,; th t | ’ L t sub J ccts drawn from the population of airline pUots who would fly the aircraft in the 
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are valuable earlier in the design process. As each modification is made to the initial concept, new 
evaluations with new test subjects should be performed. Human Factors experts may be used for 
evaluation of certain aspects of the design, as appropriate. 

(4) Test and evaluation from a usability and performance perspective should focus on measures 
that are related to mission objectives. As described in Figure 3, pilot performance and overall flight 
crew/flight deck performance, as measured by accuracy, response time, workload, situation 
awareness, subjective assessment, and training efficacy, are assumed to relate to overall mission safety 
and efficiency. Different measures are appropriate depending on the evaluation platform and stage of 
design. 


(5) Evaluations should be conducted on representations of the system at several levels of 
fidelity. For example, concept evaluations may be conducted with prototypes which can be developed 
as paper story boards or in software using rapid prototyping tools. Other evaluations may be with 
interactive computer-based prototypes or with a simulator exhibiting true vehicle flight characteristics. 
Different platforms (e.g., computer-modeled prototypes, part-task simulators, flight test vehicles, etc.) 
allow different levels of fidelity in terms of aircraft characteristics and operating environment 

(6) Evaluations should be conducted using a set of scenarios that span the range of normal and 
non-normal situations that can occur and which test the limits of human performance and overall flight 
crew/flight deck performance. 


Measures 

In evaluating operability and usability, as well as user acceptance of systems, a variety of 
measures can be used. First, system design can be evaluated in analytical ways. Design concepts can 
be evaluated against the guidelines and requirements: Do they meet the requirements and generally 
comply with good design practice as embodied in design guidelines? If they do, and the requirements 
and guidelines are reasonable, then the design is well on its way to being usable. 

In the general sense in which we use "evaluation," typically there is some sort of actual use of 
the system by an operator, so that his or her performance can be measured. The primary measure that 
is used in these types of evaluations is performance accuracy (or conversely, errors). For evaluation 
of system interfaces and system functionality, this can be accuracy in terms of tracking, decision 
making, manual input (e.g., button pushing), problem solving, or any other aspect of performance of 
tasks and functions that the flight crew and the flight crew/flight deck system must perform. Overall 
flight crew/flight deck performance can also be evaluated by constructs such as workload and situation 
awareness, with the assumption that they are correlated with performance. For overall performance, 
measurement of specific types of flight crew errors, such as those that demonstrate confusability or 
interference among different systems, system functioning, or system interfaces, is particularly useful. 

Response times are also useful evaluation measures. When competing design concepts are 
good, it is often difficult to demonstrate differences in error rates in most conditions (because so few 
errors are made), but it is typically assumed that the faster humans can respond, the more accurate they 
will be when there is little time or when other stresses are present. In human performance 
measurement, researchers refer to this phenomenon as a speed-accuracy trade-off; under most 
circumstances, as one is forced to respond more rapidly, more errors are made. If response times are 
faster in evaluations of one design over another while the accuracy levels are similar, then it is assumed 
performance with that design will be better under time constraints. 

Subjective measures arc also used, particularly early in design before the systems are well 
defined. Subjects can provide preferences and can judge the acceptability, general utility and ease of 
use of systems and system interfaces. These types of measures may be collected in structured and 
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formalized ways to reduce the many sources of bias that can influence them. Training-related 
measures are also useful for evaluation purposes. Measures such as training time and relearning or 
transfer of training time and accuracy are good ways to evaluate the "intuitiveness" of system design. 


Platforms 

Platforms are the test environment and apparatus in which the evaluation is conducted. 
Concepts modeled by computer or on paper are more naturally evaluated in those same environments, 
so the platforms are computer workstations or paper. Paper evaluations can take many forms, 
including surveys, questionnaires, and fairly formal evaluations of concepts that are described 
narratively and graphically on paper. In computer evaluations, system functions and interfaces can be 
modeled, as can the environment, operational context, and the user. Typically, computer-modeled 
prototypes are "operated" by a "real" user to collect performance data. The fidelity of these platforms 
can vary greatly. With the sophisticated graphics and modeling capabilities available today, rapidly 
developed interactive prototypes can be used early in design with a considerable degree of fidelity and 
realism. 

For many of the physical issues of design, such as reach, visibility, layout, display and control 
configuration, etc., physical mock-ups are still very useful. The realism of mock-ups can vary from 
"drawings" of displays and controls on a Styrofoam flight deck, to very realistic display, control, and 
panel surfaces on actual flight deck hardware from a previous aircraft. One of the most important 
aspects of fidelity for mock-ups, however, is spatial and dimensional realism; that is, the sizes and 
locations of displays and controls, etc., should be accurate. This can be accomplished with any type 
of mock-up. 

The highest fidelity evaluations are performe ! in simulators and flight test vehicles. Part-task 
and full mission simulations are probably the most common methods for evaluating flight deck design 
concepts. Full mission simulation, where the complete operational context and all the systems are 
simulated, is the most important tool for evaluating the effect of design concepts on overall flight 
crew/flight deck performance. It is not until full mission simulation that many subtleties of system and 
design concept interactions can be observed. Conflicts, interference, and incompatibilities among 
design components, that were necessarily developed independently, become apparent in full mission 
simulation. Since this is such an important platform and tool for evaluating total flight crew/flight deck 
performance, the earlier system design concepts can be integrated in full mission simulation, the better. 

Flight test is the final method for evaluating design concepts. Because it is very expensive, 
however, flight test should be reserved for issues that absolutely can't be evaluated without the final 
aspects of realism and fidelity that are provided by real flight. Of course, extensive flight tests 
associated with certification and final development must be performed before the aircraft goes into line 
operation. 


Methods & Tools 

Current design practices already use many evaluation tools and methodologies. Chiefly, these 
include computer aided anthropometric and biometric analyses to assess reach envelopes and other 
physical ergonomic issues, function and task analyses to determine flight crew and flight deck 
automation requirements, and workload analyses to evaluate the appropriateness of flight crew task 
loading. More extensive descriptions of a number of the following methods can be found in Macleod 
(1992) and Whitefield, Wilson & Dowell (1991), which are listed in Appendix C. 

Methods vary with the platform used and stage of design. Methods can generally be divided 
into analytical and observational methods. Analytic methods typically have cither an underlying 


theoretical basis or a complete or partial model of the user. Observational methods obtain data on 
actual operations of flight deck systems including user performance. Some of the more common 
analytical and observational methods are briefly described below. 


Analytical Methods 

Analytical methods are a class ot evaluation methods providing a detailed examination of a 
system design or of some aspect of the system's design. The purpose is to provide detailed 
information which may then be used in redesign to enhance system performance. Some analytical 
methods involve experts (as opposed to users) to evaluate some aspect of the design; other analytical 
methods employ the ultimate users of the design to perform the analysis. Some analytic methods have 
(l) an underlying theoretical basis with empirically-collected data, and/or (2) a model or some other 
representation of a) the user or some aspect of user behavior and/or b) the system being designed. 
These methods are often conducted with a computer-based tool by a human factors specialist and 
typically provide predictions concerning specific human factors aspects of a design or user 
performance. 

Anthropometry/Biomechanics Analysis. Anthropometry/Biomechanics analysis examines the physical 
layout of the environment and the "fit" of the users within that physical environment. There is 
typically an underlying model of users (e.g., 5th percentile female to 95th percentile male) from a 
defined population (e.g., the U.S. Air Force). The analysis focuses on such issues as the reach and 
viewing envelopes of individual crewmembers, the physical layout and appropriateness of lighting, 
and crew physical movements required to perform specific tasks. 

Attentional Conflict Analysis. Attentional conflict analysis is used to determine whether the systems or 
configuration ot the flight deck impose potentially serious attentional conflicts for the crew. Humans 
are, for the most part, serial processors; they are only able to attend to, process, and perform one 
activity at a time. Although certain tasks or combinations of tasks may require a pilot to manipulate 
multiple separate controls with a single hand or divide attention between multiple displays, the flight 
deck design should prevent common combinations of tasks from overtaxing the pilot’s attentional 
(e.g., visual, auditory, and cognitive) resources. One method of analyzing the flight deck for 
attentional conflicts is to apply the Multiple Resource Theory of human attention (Wickens, 1984), 
which rank orders different types of conflicts. For example, the theory, and the model derived from it 
based on extensive dual task studies, indicate that visual/visual conflicts are more difficult to manage 
than visual/auditory conflicts. Computer-based tools based on multiple resource theory, such as 
W/INDEX (North & Riley, 1988; Riley, Lyall, Cooper, & Wiener, 1993), can be used to estimate the 
effects of specific task sequences and procedures based on these conflicts. 

Cognitive Task Analvsis/Cogni tive Engineering. Cognitive engineering applies theories of cognitive 
science to design; that is, one attempts to systematically apply what is known from empirical studies of 
human cognition and performance to the design of complex, computer-based human/machine systems 
(Rasmussen, 1986; Norman, 1986; Woods & Roth, 1988). Cognitive task analysis goes beyond a 
typical task analysis (i.e., one that analyzes tasks and subtasks in terms of their occurrence in a 
sequence, duration, supporting information, etc.) and includes consideration of underlying 
psychological factors (e.g., memory, decision making, complexity). 

Cognitive Walkthrough. A cognitive walkthrough is a recently-developed, formally structured, 
analytical method for evaluating user/system interfaces very early in the design process. The 
developers (Lewis. Poison, Wharton, and Rieman, 1990; Poison, Lewis, Rieman, and Wharton, 
1992) based this analytical method on CE+, a cognitive theory of learning (Poison & Lewis, 1990). 
The method involves analyzing a user's task to a detailed level, then answering a series of questions 
about the task which, in effect, evaluate the leamability of the proposed system (e.g., what are the 
user’s current goals?; is the system’s response adequate?; can the user detect when the task is 
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completed?). The results of the analysis indicate problem area within the interface which should be 
considered for redesign. One particular advantage of this method is that it may be conducted prior to 
having a working prototype of the system. Rieman, et al„ (1991) recently developed an automated 
tool to perform cognitive walkthroughs. 

Expert Walkthrough. Expert walkthroughs involve usability evaluations or judgments of systems by 
human experts. These experts are typically drawn from a number of fields (e.g., pilots, human factors 
specialists). The experts independently step through typical user’s tasks and critically evaluate the 
proposed design. This "walkthrough" is often accomplished with a prototype of the system in design 
and with structured evaluation instruments (e.g., a checklist of evaluation items). 

Heuristic Evaluation hv Designers With heuristic evaluation by designers, members of the design 
team independently (and, often, informally) assess the usability of a system and pool the evaluation 
results across the team. These pooled results are then used to guide the redesign. 

Keystroke-Level Model Analysis. Keystroke-level model analysis is an analytic method derived from 
the work of Card, Moran, and Newell ( 1983) and is one of a class of GOMS (goals-operators- 
methods-selection rules) analytical methods. A user model including a number of user performance 
and system response parameters and associated times (e.g., keystroking, pointing), derived from 
empirical studies, underlies these analyses. The method provides predictions about times required to 
complete a task, assuming error-free user performance. Using this method, one may compare the 
actual keystrokes of users who have completed a task to a model of predicted task completion times; 
the method may also provide a benchmark of predicted task completion times against which to compare 
systems or design approaches. 

Structured Interviews. Structured interviews allow members of a design team to step through a 
prototype of the system and directly ask an user a series of questions about its use. A pre-determined 
series of questions is asked and the user is led through the interview, which may be structured by use 
of an operations scenario. Otten, structured interviews are videotaped for later detailed review and 
analysis. 

Survey Methods & Questionnaires. Surveys and questionnaires involve the structured collection and 
analysis of users' subjective opinions about a proposed design. They are usually conducted without 
the physical presence of a system or prototype, so they are especially useful for evaluation of 
conceptual designs. Data are collected when users are not actually interacting with the system. Users' 
subjective opinions are probed with a series of specific "closed" questions (i.e., the answers are 
constrained) concerning aspects of the system's design and use. In addition, open-ended questions 
(i.e., questions that allow a user's free comments to a specific question rather than choosing from a list 
of responses) are often used, especially in very early phases of design. 

Function and Task Analysis. Function and task analyses have traditionally referred to the process of 
identifying, decomposing, and allocating lunctions. and describing specific human tasks in terms of 
the sets of activities and information that are required to accomplish them. These methods have been 
used primarily to develop task timelines and to help determine crew interface requirements. In the 
revised crew-centered design process, however, task analysis also incorporates an examination of how 
flight crew members perform their tasks in existing aircraft to determine how they may need to do 
these same tasks in a new flight deck. The operational environment is also examined to determine 
what functions must be provided, and flight crew activities in current flight decks are examined to 
determine how the crew actually fulfills these (unctions. These analyses point out two special kinds of 
problems: ( 1 ) the crew has to “trick” the flight deck automation to achieve the desired result; or (2) the 
automation goes unused because the crew feels they have better control by completing the task 
manually, or at a lower level of automation. Such areas indicate possible shortcomings in the 
functionality or interface provided by the automation, and suggest how new systems can better meet 
the crew’s needs. 
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Trade Studio, Trade studies are analyses focused on answering specific questions within a design 
program by systematically comparing alternatives with a set of cost and benefit criteria. They are 
usually paper-based and involve collecting specific data that allow one to compare and choose among a 
devek^ment 1 * ^ ^ g ’ choosing betwcen specific implementation technologies) or a specific path of 


Observational Methods 

Observational methods involve viewing and analyzing user behavior with a system or 
prototype ot a system. Observational evaluations involve creating a situation similar to the operational 
environment and observing users performing a set of representative tasks within this environment 
These evaluations may be formal and highly-structured (e.g., in the form of controlled experiments) or 
informal and less structured, and may use individual or multiple users. The fidelity of the simulation 
ot the operational environment varies and may range from rapid prototypes to full flight simulators. 
Typically the user sessions are recorded (e.g., by videotape or by keystrokes captured within a 
computer file) tor later detailed analysis. In addition to videotaping a user performing a task, direct 
user actions with the system may be automatically collected. All of a user’s actions (e.g., keystrokes; 
mouse clicks; button pushes) may be accessed within the system itself, time-stamped, and sent to a 
data file tor later analysis. These data essentially allow an analyst to replay the user's entire interaction 
with a system alter the task is completed. 

Cooperative Evaluation. Cooperative evaluation actively involves users in the evaluation of the 
prototype system design. Members of the design team observe users as they carry out tasks with the 
prototype system. Users may be interviewed directly when they encounter difficulty, or to minimize 
interference, upon task completion. A videotape of the user while performing the task may be used as 
a reminder during retrospective analysis. It multiple users perform the task simultaneously, their 
conversations (especially when solving a problem with system use) may also serve as useful data. 

Direct Observation . 1° direct observation, the user carries out a representative task on a prototype of 
the system. An expert (e.g., human factors specialist; pilot) directly observes the user and records 
problems that occur with the user/system interaction. This information is then used in redesigning the 
system. Direct observation may be used with other observation methods. 

Experiments. Experiments allow deliberate manipulation of specific factors involving the user's 
interaction with a prototype system. Elements of the interface and the task may be manipulated, as 
well as operational and environmental factors. Experiments allow the opportunity to collect 
user/system interaction data within a more- controlled environment than that of other evaluation 
methods. User performance data (typically, a combination of objective and subjective measures) are 
collected, analyzed, and related to the faciors manipulated. Because of the controlled nature of 
experiments, they are often used to test hypotheses concerning interface design. The primary 
advantage of a controlled experiment is that it allows test of specific factors and their interactions; the 
primary disadvantage is that a controlled experiment often doesn't capture the complete set of factors 
that, in combination, comprise the real-world operating environment. The results may, therefore, have 
limited generality to the usability of the design in an uncontrolled operational context. Experiments are 
often complex and time-consuming, although they need not be. This approach is typically useful in 
system design when evaluating user performance with system components (e.g., window designs; 
symbol sets, fonts, control devices), rather than when evaluating the system as a whole. Experiments 
may be carried out within a laboratory or simulator with variable levels of fidelity. 

PrQtQWQ l An al ys i s . Protocol analysis evaluates user interaction with a system by analyzing the user's 
utterances during task performance (Ericsson & Simon, 1993). In this method, users are often asked 
to think aloud” and describe their activities while performing a representative task. This "think aloud" 
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APPENDIX B: HSR ASSUMPTIONS 


The following assumptions are drawn from the list currently maintained by the HSR Flight 
Deck Design and Integration Element, and is a consensus collection of the assumptions generated by 
all the various elements of the HSR Flight Deck program. The attention given in this document to the 
list of assumptions is warranted; the assumptions provide the context for application of the philosophy 
statements, the guiding principles, and the categories of design guidelines to requirements and system 
specification development for the HSCT. Without this context, the translation of the principles into a 
specific set of requirements or a specific flight deck design could become arguable. For example, the 
approximate year that the first aircraft may be manufactured helps to establish the expected level of 
automation technology that should exist, which may influence the ability to adhere to some principles. 

New assumptions are constantly being added to the ones presented below. In addition, 
existing assumptions are periodically scrutinized to ensure that progress in the research program has 
not invalidated them. To receive the latest list of HSR assumptions, please contact Michael T. Palmer 
by telephone at +1 804 864-2044 or via email (preferred method) at m.t.palmer@larc.nasa.gov. 

A - 1 . The HSCT will nominally be operated by a two person crew, but either flight crew member 
alone must be able to safely complete the flight 

A - 2 . The design of the aircraft will be completed in time for an approximate 2005 roll-out of the 
first aircraft. 

A - 3 . The HSCT will receive no preferential treatment with respect to traffic flow management in 
the terminal area, with the following exceptions: 

a. The HSCT may require special separation from other airplanes as it will climb out on 
departure at significantly greater speeds than 250 KCAS below 10,000 ft. 

b . The HSCT may require special separation from subsonic airplanes or other departure 
routing from 10,000 ft. to 43,000 ft. due to steep climb angles and supersonic speeds 
during climb and acceleration. 

c. During subsonic cruise, the HSCT may require special separation due to slightly higher 
subsonic cruise Mach numbers over subsonic airplanes. 

A - 4 , The HSCT will not have a "drooped nose." 

A - 5. Tire HSCT will have "manual" flight controls (to the extent that the pilots can "hand-fly" 

the airplane). 

A * 6 . Improved capability technologies will be available in time to support the HSCT design. 

This is explicitly assumed for computer hardware, especially with regard to memory size, 
cost, display capability, and processing speed. 

A - 7. All aspects of the aircraft system, including hardware, software, procedures, and training, 

will be designed concurrently, and the design process will allow each aspect to influence 
the other design processes. 

A * 8 . Minimum FAR Part 25 (certification) changes are expected from existing rules, except 

where required for unique HSCT capabilities. 

A - 9 . The projected 2005 environment for the 747-400 defines the baseline subsonic operational 

environment for weather requirements, visibility requirements, airport characteiistics, 
handling characteristics, avionics capability, and CRAF/charter requirements. 
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A - 1 0. The HSCT will carry reserve fuel, and will be subject to "ETOPS-like" considerations for 
over-water flights. 

A - 1 1 . The HSCT flight deck will incorporate an open architecture design, which means that the 

llight deck will not be a single point design, but rather will be a framework for a family of 
flight decks with differing functionality as dictated by individual airline customer 
requirements. 

A - 1 2 . HSCT aircraft will have traditional subsystems, largely similar to current generation 

subsonic transports, including: fuel, hydraulic, electrical power, avionics/computation, 
sensors (weather and/or traffic radar), and communications (VHF voice and data link radio, 
ACARS or similar follow-on data link). 

A * 1 3 . Commercial and corporate aircraft will have Mode S transponders or equivalent, with 

discrete addressing, altitude encoding, and data link capability. General aviation aircraft 
operating in Class B and Class C airspace will be equipped with at least Mode C 
transponders; however, ATC-authorized deviations from this requirement will still be 
available. In other airspace, general aviation aircraft may not be carrying transponders. 

A - 1 4 . All commercial and turbine-powered general aviation aircraft will be equipped with TCAS 
II, and will likely be required to be equipped with a more advanced form of traffic/collision 
avoidance system. 

A- 1 5. National Oceanic and Atmospheric Administration (NOAA) and Jeppesen IFR procedures 
and reterence data will be available in electronic form and will be legal for navigation in 
national/intemational airspace systems. 

A - 1 6 . Airline pilots will not be assigned to the HSCT for the duration of their careers; rather, 
piloLs will transter into the HSCT with at least some experience flying subsonic jet 
transports, and will be able to return to flying subsonic airplanes after flying the HSCT. 
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